Digital document management system, digital document management method, and digital document management program

ABSTRACT

Disclosed is a digital document management program capable of achieving a third-party certification of document information with reduced amount of meta data. At the registration time of new document information, the digital document management program manages a digital signature created in association with document information. At the correction time of the document information, the program acquires partial identification information related to a corrected part of the document information before correction, creates a digital signature to be appended to the corrected document information, and manages the digital signature and partial identification information related to the corrected part of the document information in association with the corrected document information. At the verification time, the program uses partial identification information, the partial identification information corresponding to a corrected part of the document information before correction, and digital signature to perform verification.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a digital document management system orthe like that manage document information including digital informationand, more particularly, to a digital document management system, adigital document management method, and a digital document managementprogram which are applied to digitization, distribution, storage of adocument that needs weight of evidence as heavy as that a paper documentprovides and which are capable of easily identifying a corrected part indigital document information involving a partial correction (including,e.g., addition, change, deletion, sanitizing), guaranteeing the validityof the correction, and performing a third-party certification of thecorrection.

2. Description of the Related Art

As a prior art, a correction method and verification method of thevalidity of the correction used in a paper document will firstly bedescribed.

Conventionally, as a representative correction method for use inperforming correction for a paper document, there is known a method asshown in FIG. 69. That is, the method includes: crossing out charactersto be corrected with a double line and entering proper characters in thespace immediately above the correction (P1), putting signatures(initials) of both parties thereto (P2). Note that, in drawings,hereinafter, where the correction is made with a seal (name in acircle), this means the above correction method, that is, it correspondsto putting signatures of both parties thereto.

It is possible to guarantee/confirm the following points by conductingthe above P1 and P2 in the conventional correction method for a paperdocument.

(1) Capable of easily confirming/identifying a corrected part, as wellas capable of confirming that any other part than the corrected partincludes no deliberate or negligent change.

(2) Capable of easily confirming/identifying corrected area.

(3) Capable of easily confirming a person who has made the correction.

(4) Capable of confirming whether the corrected part is a correctablepart.

(5) Capable of confirming the original before correction.

(6) Capable of making a correction and verifying the correctionaccording to a policy (control information) related to corrections.

Similarly, it is possible to guarantee/confirm the following points inthe conventional correction method for a paper document withcarbon-copied paper used for an insurance application form,transportation order form, or the like.

(7) Capable of partially hiding the document, as well as confirming thatany other part than the hidden part includes no change.

(8) Capable of confirming the identity between a base paper andcarbon-copied paper by comparing handwritings on respective papers.

(9) Capable of detecting falsification of document by separately storingthe base paper and carbon-copied paper.

(10) Capable of performing a third-party certification related to thecontent of the document, even if being brought in court case, accordingto (9).

(11) The base paper and carbon-copied paper can be distributed asneeded. In some cases, they can independently be distributed of eachother.

As described above, a correction method and a method of certificatingthe validity of the correction in a paper document are excellent invarious points. Meanwhile, along with recent advancement in ITtechnology, a technique that handles digital data (digital information)in place of the above paper document in view of convenience of datahandling and data storage has been proposed (refer to, e.g., Jpn. Pat.Appln. Laid-Open Publications Nos. 2000-285024, 2001-117820, and2003-114884, Paper of Information Processing Society of Japan/ComputerSecurity Group (CSEC) “Digital document sanitizing problem (2003/7/17)(2003-CSEC-22-009)”, and Paper of SCIS2004 “A Digital DocumentSanitizing Scheme with Disclosure Condition Control”).

The above publications Nos. 2000-285024 and 2001-117820, which relate toa technique of storing the original of a digital document, proposetechniques that give the properties that the original document (paperdocument) has to digital information and protect the digital documentfrom being falsified. That is, these techniques focus that a mechanismfor storing and managing a digital document of the final fixed versionas an original document, that is, the storage location of the originaldocument is made evident and focus how safely the original documentsaccumulated within an organization are stored.

However, in such an original document storage technique, even when onlyminor corrections are made for a digital document, it is regarded as“falsification”. For example, in the case of the abovementioned“corrections for paper agreement document”, a correction procedure of“crossing out word to be corrected with a double line, enteringcorrected word in the space immediately above the correction, andputting signatures of both parties”. In this case, even aftercorrections have been made for the paper agreement document, it isregarded as an original document.

The above correction procedure in a paper society is publicly judged tobe valid and therefore the corrections made can be confirmed through athird-party certification.

On the other hand, in the case, even if the conventional originaldocument storage technique, a problem that it is impossible to determinewhether corrections are “falsification” or “proper change”. This canalso be explained from the current feature of a digital signature whichcan detect every change made for a digital document.

The above publication No. 2003-114884, which relates to a digitaldocument editing/displaying technique, proposes a technique forperforming correction, addition and display control for a digitaldocument on an element basis while guaranteeing the originality of thedigital document without dividing the digital document into a pluralityof parts. In this technique, original document information isconstituted and managed by one file including actual data correspondingto original document information and a definition describing control foreach element. When corrections or additions are made, they aredescribed/added in/to the definition as correction information. As aresult, a third-party certification related to the correctioninformation can be achieved.

In this technique, however, it is necessary to reveal all correctioninformation including previous versions in order to obtain a third-partycertification. That is, a third-party certification cannot be achievedwith a document a part of which is hidden (sanitized) or only with someversions.

The above paper “Digital document sanitizing problem” of CSEC, whichrelates to a digital document sanitizing technique, proposes asanitizing technique applied to a digital document that solves a problemthat a signature appended to a given document cannot be verified when apart of the document is made confidential. An application of the digitaldocument sanitizing technique disclosed in the paper makes it possibleto perform the signature verification even when sanitizing is applied toa digital document with a signature, to perform a third-partycertification to certify that any other part than the sanitized partincludes no change, and to perform “a third-party certification with adocument a part of which is hidden (sanitized)” which has been pointedout as a problem of the publication no. 2003-114884.

In the digital document sanitizing technique of the paper, however, acreator of the original document is assured but it is impossible toidentify who has performed the sanitizing. Further, the paper takes upthe digital document sanitizing problem with a system of public offeringof information as a usage scene of a digital document and has notmentioned about further utilization of the digital document under thecondition that the document including some sanitized portions isdistributed among a plurality of entities.

SUMMARY OF THE INVENTION

The present invention has been made to solve the above problems and anobject thereof is to provide a digital document management system, adigital document management method, and a digital document managementprogram capable of, in the process where a digital document isdistributed among a plurality of entities: identifying a corrected partin digital document including a partial correction (including, e.g.,addition, change, deletion); confirming that any other part than thecorrected part includes no change; identifying/confirming who has madethe partial correction for the digital document; guaranteeing that thepartial correction has been made according to a proper procedure; andachieving a third-party certification of the validity of the aboveconfirmations or identifications.

To solve the above problems, according to a first aspect of the presentinvention, there is provided a digital document management program thatallows a computer to manage document information created and registeredin a digital form, the program allowing the computer to execute: apartial identification information generation step that divides thedocument information into a plurality of parts and generates partialidentification information that represents, in an identifiable manner,the respective parts of the document information based on informationincluded in the respective parts; a digital signature creation step thatcreates a digital signature to be appended to the document informationusing the partial identification information; a management step thatmanages the document information; and a verification step that verifiesthe validity of the managed document information, wherein at theregistration time of new document information, the management stepmanages a digital signature created by the digital signature creationstep in association with the document information and, at the correctiontime of the document information, it acquires partial identificationinformation related to a corrected part of the document informationbefore correction, allows the digital signature creation step to createa digital signature to be appended to the corrected documentinformation, and manages the digital signature and partialidentification information related to the corrected part of the documentinformation before correction in association with the corrected documentinformation, and the verification step uses the partial identificationinformation and digital signature managed in association with thecorrected document information by the management step and partialidentification information newly created from the corrected documentinformation by the partial identification information generation step toperform the verification.

In the digital document management program according to the presentinvention, the digital signature creation step uses a set of partialidentification information created by the partial identificationinformation generation step and a private key as parameters to create adigital signature according to a signature function.

In the digital document management program according to the presentinvention, the digital signature creation step uses an Aggregatesignature function which is a kind of a group signature scheme and whichis capable of aggregating a plurality of signatures on one signature.

In the digital document management program according to the presentinvention, the partial identification information managed in associationwith the corrected document information is managed separately from thecorrected document information data.

In the digital document management program according to the presentinvention, the partial identification information is managed by beingembedded in the corrected document information.

The digital document management program according to the presentinvention further comprises: a policy information storage step thatstores previously defined policy information; and a partial correctioninformation generation step that generates partial correctioninformation which is information related to a correction history of acorrected part in the case where any correction has been made for thedocument information, wherein in the case where any correction has beenmade for a part of the document information, the management step allowsthe partial correction information generation step to generate partialcorrection information and manages the generated partial correctioninformation and policy information stored by the policy informationstorage step in association with the corrected document information, andthe verification step uses the partial correction information and policyinformation in addition to the partial identification information andsignature information managed in association with the corrected documentinformation by the management step to verify the validity of thedocument information.

In the digital document management program according to the presentinvention, the partial identification information generation stepdivides document information into a plurality of parts and uses a hashfunction to generate partial identification information for respectiveparts of the document information.

In the digital document management program according to the presentinvention, the information managed by the management step is constitutedby XML data having a hierarchical document structure.

In the digital document management program according to the presentinvention, the management step handles all digital information asoriginal document information corresponding to version numbers, and anaccess to the content of the original document information managed basedon its version numbers can be controlled depending on the contentthereof in the respective versions in an identifiable manner.

According to a second aspect of the present invention, there is provideda digital document management system that manages document informationcreated and registered in a digital form, comprising: a partialidentification information generation section that divides the documentinformation into a plurality of parts and generates partialidentification information that represents, in an identifiable manner,the respective parts of the document information based on informationincluded in the respective parts; a digital signature creation sectionthat creates a digital signature to be appended to the documentinformation using the partial identification information; a managementsection that manages the document information; and a verificationsection that verifies the validity of the managed document information,wherein at the registration time of new document information themanagement section manages a digital signature created by the digitalsignature creation section in association with the document informationand, at the correction time of the document information, it acquirespartial identification information related to a corrected part of thedocument information before correction, allows the digital signaturecreation section to create a digital signature to be appended to thecorrected document information, and manages the digital signature andpartial identification information related to the corrected part of thedocument information before correction in association with the correcteddocument information, and the verification section uses the partialidentification information and digital signature managed in associationwith the corrected document information by the management section andpartial identification information newly created from the correcteddocument information by the partial identification informationgeneration section to perform the verification.

According to a third aspect of the present invention, there is provideda digital document management method that manages document informationcreated and registered in a digital form by a computer, comprising: apartial identification information generation step that divides thedocument information into a plurality of parts and generates partialidentification information that represents, in an identifiable manner,the respective parts of the document information based on informationincluded in the respective parts; a digital signature creation step thatcreates a digital signature to be appended to the document informationusing the partial identification information; a management step thatmanages the document information; and a verification step that verifiesthe validity of the managed document information, wherein at theregistration time of new document information, the management stepmanages a digital signature created by the digital signature creationstep in association with the document information and, at the correctiontime of the document information, it acquires partial identificationinformation related to a corrected part of the document informationbefore correction, allows the digital signature creation section tocreate a digital signature to be appended to the corrected documentinformation, and manages the digital signature and partialidentification information related to the corrected part of the documentinformation before correction in association with the corrected documentinformation, and the verification step uses the partial identificationinformation and digital signature managed in association with thecorrected document information by the management step and partialidentification information newly created from the corrected documentinformation by the partial identification information generation step toperform the verification. According to the present invention, it ispossible to satisfy the following requirements which cannot be met byconventional techniques and a plain combination thereof by managing varysmall amount of meta data.

(1) Capable of identifying a corrected part in the digital document aswell as confirming that any other part than the corrected part includesno change.

(2) Capable of assuring (independently certificating) the integrity andauthenticity of the digital document at each time point in the casewhere a corrected digital document is distributed between a plurality ofentities and a correction/addition is made for the digital document atthe respective entities.

(3) Capable of performing a third-party certification and distributionusing a digital document that has been subjected to sanitizing or usingonly some versions even though all the versions of the digital documentstored/managed in the present system are not taken out.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a view showing an underlying technique of the presentinvention;

FIG. 2 is a block diagram functionally showing a configuration of adigital document management system as the underlying technique of thepresent invention;

FIG. 3 is a view showing an example of policy information;

FIG. 4 is a view showing an example of partial identificationinformation;

FIG. 5 shows a storage state at the new document registration time;

FIG. 6 is a flowchart showing operation of new document registrationprocessing;

FIG. 7 is a view showing an example in which a correctable area andnon-correctable area are identified;

FIG. 8 is a view showing an example of partial correction information;

FIG. 9 is a view showing a storage state at the registration documentcorrection time;

FIG. 10 is a flowchart showing operation of registration documentcorrection processing;

FIG. 11 is a view showing the correction policy information and partialcorrection information to be compared;

FIG. 12 is a view showing the agreement document and partialidentification information to be compared;

FIG. 13 is a view showing a new version of partial identificationinformation and a previous version of partial identification informationto be compared;

FIG. 14 is a flowchart showing operation of registration documentverification processing;

FIG. 15 is a view conceptually showing the usage scene in a secondphase;

FIG. 16 is a view showing an original document storage state at theregistration document correction (partial sanitizing) time;

FIG. 17 is a view showing a complete set of agreement document to betransmitted;

FIG. 18 is a flowchart showing operation of registration documentdistribution (transmission) processing;

FIG. 19 is a flowchart showing operation of reception processing of adocument to be registered;

FIG. 20 is a flowchart showing operation of registration documentacquisition processing;

FIG. 21 is a view showing a third-party certification 1;

FIG. 22 is a view showing a third-party certification 2;

FIG. 23 is a view showing a third-party certification 3;

FIG. 24 is a view showing the usage scene of the second applicationfield in underlying technique 2;

FIG. 25 is a view showing an example in which the main body of aninsurance application form (first version) is represented using XMLdata;

FIG. 26 is a view showing an XML data model of the insurance applicationform (first version);

FIG. 27 is a view showing an example in which partial identificationinformation generated at the creation time of the insurance applicationform (first version) is represented using XML data;

FIG. 28 is a view showing the XML data model constituted only by a setof “contractor”;

FIG. 29 is an original document storage state at the creation time ofthe insurance application form (first version);

FIG. 30 is a view showing an example in which an updated insuranceapplication form-main body (second version) is represented using XMLdata;

FIG. 31 is a view showing an example in which an insurance applicationform—partial identification information (second version) is representedusing XML data;

FIG. 32 is a view showing an original document storage state at thecreation time of an insurance application form (second version);

FIG. 33 is a view showing a verification data group that a financialinstitution representative can review;

FIG. 34 is a view showing an example in which an insurance applicationform—main body (third version) is represented using XML data;

FIG. 35 is a view showing an example in which an insurance applicationform—partial identification information (third version) is representedusing XML data;

FIG. 36 is a view showing an original document storage state at thecreation time of the insurance application form (third version);

FIG. 37 is a view showing coupling-management of all the partialidentification information required for verifying the second version;

FIG. 38 a view showing coupling-management of all the partialidentification information required for verifying the third version;

FIG. 39 is a view showing an example in which the method 2 is used torepresent the partial identification information (second version) usingXML data;

FIG. 40 is a view showing an original document storage state at thecreation time of the insurance application form (third version) in themethod 2;

FIG. 41 is a view showing an example of XML data forevaluation/analysis;

FIG. 42 is a view showing the update of XML data forevaluation/analysis;

FIG. 43 is a view showing generation and verification of the partialidentification information according to the method 0;

FIG. 44 is a view showing generation and verification of the partialidentification information according to the method 1;

FIG. 45 is a view showing generation and verification of the partialidentification information according to the method 2;

FIG. 46 shows a result of method-based analysis;

FIG. 47 shows a bubble chart representing the result of the method-basedanalysis;

FIG. 48 is a view showing the overview of the processing of theunderlying technique 1;

FIG. 49 is a view showing the overview of the processing of theunderlying technique 2;

FIG. 50 is a block diagram showing a configuration of an embodiment ofthe present invention;

FIG. 51 is a view showing operation performed at the signature time inthe first embodiment;

FIG. 52 is a view showing operation performed at the first sanitizingtime in the first embodiment;

FIG. 53 is a view showing operation performed at the second andsubsequent sanitizing time in the first embodiment;

FIG. 54 is a view showing operation performed at the signatureverification time in the first embodiment;

FIG. 55 is a view schematically showing effects of the first embodimentin comparison with the underlying technique;

FIG. 56 is a view showing the overview of the operation performed in thefirst embodiment;

FIG. 57 is a view showing operation performed at the signature time in asecond embodiment;

FIG. 58 is a view showing operation performed at the first sanitizingtime in the second embodiment;

FIG. 59 is a view showing operation performed at the second andsubsequent sanitizing time in the second embodiment;

FIG. 60 is a view showing operation performed at the signatureverification time in the second embodiment;

FIG. 61 is a view schematically showing effects of the first embodimentand second embodiment in comparison with the underlying technique;

FIG. 62 is a view showing the overview of the operation performed in thesecond embodiment;

FIG. 63 is a view showing operation performed at the signature time in athird embodiment;

FIG. 64 is a view showing operation performed at the first sanitizingtime in the third embodiment;

FIG. 65 is a view showing operation performed at the second andsubsequent sanitizing time in the third embodiment;

FIG. 66 is a view showing operation performed at the signatureverification time in the third embodiment;

FIG. 67 is a view showing the overview of the operation performed in thethird embodiment;

FIG. 68 is a view schematically showing effects of the third embodimentin comparison with the underlying technique; and

FIG. 69 is a view showing an example of a conventional paper agreementdocument that has been corrected.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Hereinafter, an underlying technique of the present invention will bedescribed with reference to the drawings before description of theembodiment is given.

(Underlying Technique)

A digital document management system, which is an underlying techniqueof the present invention, retains, independently of document informationserving as a digital document composed of digital information, policyinformation (policy information for registration and policy informationfor correction) and partial integrity information (partialidentification information and partial correction information) andprovides a mechanism that verifies and distributes the digital documentas a digital document partial integrity assurance system.

FIG. 1 is a view of the principle of a digital document managementsystem according to the present invention. Firstly, the basicconfiguration of the digital document management system will bedescribed with reference to FIG. 1. Note that, in the presentspecification, “document information” and “original documentinformation”, “document” and “original document”, are synonymous termsrespectively.

The digital document management system shown in FIG. 1 includes aregistration section 1, a generation section 2, a management section 3,a verification section 4, and a distribution section 5.

The registration section 1 registers document information composed ofdigital information as original document information. The generationsection 2 generates partial identification information for identifying apartial correction, change, addition, deletion, and the like(hereinafter, referred collectively to as “correction”) and partialcorrection information representing partial correction history of theoriginal document information.

The management section 3 manages the partial identification informationand partial correction information as partial integrity informationtogether with the original document information. Further, the managementsection 3 associates the two information with the policy information.

At the registration time of the original document information, thepolicy information is used as registration policy information, i.e.,information describing conditions including required entries (requireddocument information) in the original document information, creator'sauthority, and the like. At the time of correction of the originaldocument information after registration, the policy information is usedas correction policy information, i.e., information describing partialcorrection management control information (corrector, correctable area,non-correctable area, and the like), procedure, constraint, condition,and the like which are previously set for the original documentinformation. Note that, in the present underlying technique, identicalcorrection policy information and identical registration information areused.

In the case of a paper agreement document, sections to be filled with,corrector, correction operation, correction procedure are regulated by acode or the like. Similarly, in the case of the document informationcomposed of digital information, a section that performs operationcontrol and validates the operation control is provided.

The verification section 4 uses the correction policy information andpartial integrity information to verify that a partial correction hasproperly been made for the original document information.

The distribution section 5 constitutes a transmitting/receiving sectionthat transmits and receives the original document information todistribute the original document information among a plurality ofentities.

The original document information that the registration section 1registers corresponds to a document (e.g., critical document such asarticles of agreement) requiring a third-party certification for use asevidence if end up in court afterward. The registered original documentinformation is stored in the registration section 1. The partialidentification information and partial correction information that thegeneration section 2 generates are for post-confirmation of a correctionmade for the original document information that has been registered inthe registration section 1 and associated with the original documentinformation. When a correction is made for the original documentinformation stored in the registration section 1, a new version iscreated and stored with a previous version left without change, andpartial integrity information corresponding to the new version number isgenerated and associated with other information.

According to the above digital document management system, it ispossible to: clearly identify a correction made for a digital documentsuch as the abovementioned original document information; guarantee thatthe partial correction has properly been made; distribute the correcteddigital document (document information) among a plurality of entities;and assure the integrity of the corrected digital document at eachentity.

(Underlying Technique 1)

Hereinafter, as an underlying technique 1 of the present invention, acase where the underlying technique of the present invention is appliedto a first application field will be described. FIG. 2 is a blockdiagram functionally showing a configuration of the digital documentmanagement system as the underlying technique of the present invention.

A digital document management system 10 shown in FIG. 2 includes arequest analysis section 20, a policy management section 30, an originaldocument information management section 40, a partial integrityinformation generation section 50, a partial integrity informationverification section 60, and a distribution management section 70.

Configurations and rolls of the above sections will be described below.

The request analysis section 20 receives a processing request from auser 90 and assigns the processing to the policy management section 30or original document management section 40 according to the content ofthe request. The policy management section 30 stores and verifies policyinformation corresponding to original document information.

The policy information describes, with respect to the correspondingoriginal document information, required entries and creator's authorityat the registration (creation) time of the original documentinformation, or predetermined partial correction management controlinformation (corrector, correctable area, non-correctable area, and thelike), procedure, constraint, condition, and the like.

In the case of a paper agreement document, sections to be filled with,corrector, correction operation, correction procedure are regulated by acode or the like. Similarly, in the case of digital information, asection that performs operation control and validates the operationcontrol is provided. The policy management section 30 includes twosub-elements: a policy storage section 31 and a set of registrationpolicy verification section 32 a and correction policy verificationsection 32 b.

The policy storage section 31 receives a policy storage request from therequest analysis section 20 and, according to the request,registers/stores the policy information. The registration policyverification section 32 a verifies, according to the registration policyinformation that has already been stored in the policy storage section31, whether the creator corresponds to one who has been previouslyregistered at the registration time of the original documentinformation, or whether all required entries are made. The correctionpolicy verification section 32 b verifies, according to the correctionpolicy information that has already been registered in the policystorage section 31, whether the original document information is createdand corrected properly.

The original document management section 40 associates, together withpartial integrity information, the policy information registered in thepolicy management section 30 with digital information andregisters/manages/stores the associated information as original documentinformation. The original document management section 40 includes twosub-elements: an original document processing section 41 and an originaldocument storage section 42.

The original document processing section 41 receives a processingrequest from the request analysis section 20 and, according to therequest, performs various processing for the original documentinformation. The original document processing section 41 can execute newdata registration processing (original document registrationprocessing), registration data correction processing (registrationoriginal document correction processing), registration data acquisitionprocessing (registration original document acquisition processing), andregistration data verification processing (registration originaldocument verification processing).

The original document storage section 42 receives an original documentregistration/storage request from the original document processingsection 41 and, according to the request, registers/storages theoriginal document information together with the partial integrityinformation. Further, the original document storage section 42 receivesan original document information acquisition request from the originaldocument processing section 41 and, according to the request, takes outthe original document information and partial integrity information.

The partial integrity information generation section 50 receives apartial integrity information generation request from the originaldocument management section 40 and, according to the request, generatespartial identification information and partial correction informationcorresponding to the original document information. The partialintegrity information generation section 50 includes two sub-elements: apartial identification information generation section 51 and a partialcorrection information generation section 52.

The partial identification information generation section 51 receives apartial identification information generation request from the originaldocument management section 40 and, according to the request, generatespartial identification information (information representing respectiveparts of the original document information and entries thereof in anidentifiable manner) corresponding to the original document information.The partial identification information describes, e.g., hash informationthat includes random numbers for respective parts so as to checkpresence/absence of a change in the respective (e.g., in units of onecharacter or in units of one element in the case of XML data) parts ofthe original document information and position information indicatingcorrespondence between the section and hash information.

The partial correction information generation section 52 receives apartial correction information generation request from the originaldocument management section 40 and, according to the request, generatespartial correction information corresponding to the original documentinformation. The partial correction information describes, e.g.,information (correction history in respective parts of the originaldocument information) like “When a correction has been made”, “Who hasmade a correction”, “For which part a correction has been made”, “How adocument has been changed”, “Information before correction”, “Reason forcorrection”.

The partial integrity information verification section 60 receives apartial integrity information verification request from the originaldocument management section 40 and, according to the request, verifiespartial identification information and partial correction informationagainst corresponding original document information. The partialintegrity information verification section 60 includes two sub-elements:a partial identification information verification section 61 and apartial correction information verification section 62.

The partial identification information verification section 61 receivesa partial identification information verification request from theoriginal document management section 40 and, according to the request,verifies partial identification information against correspondingoriginal document information.

The partial correction information verification section 62 receives apartial correction information verification request from the originaldocument management section 40 and, according to the request, verifiespartial correction information against corresponding original documentinformation.

The distribution management section 70 receives a transmission/receptionrequest of original document information from the original documentmanagement section 40 and, according to the request, transmits andreceives the original document information together with partialintegrity information. The distribution management section 70 includestwo sub-elements: a transmission processing section 71 and a receptionprocessing section 72.

The transmission processing section 71 receives a transmission requestof original document information from the original document managementsection 40 and, according to the request, transmits the originaldocument information together with partial integrity information to atarget entity. The reception processing section 72 receives a receptionrequest of original document information from the original documentmanagement section 40 and, according to the request, receives theoriginal document information together with partial integrityinformation from a target entity.

Here, the underlying technique of the present invention is divided intofirst and second application fields, and deception will be given foreach sector. Firstly, in the first sector, operations related to thebasic concept (individual basic functions) of the present inventionincluding “document creation function”, “correction (partial sanitizing)function”, “verification function”, “distribution function”, and“acquisition function” will be described. In the second applicationfield, description will be concentrated on XML (extensible MarkupLanguage) document for the purpose of further modifying and improvingthe original document management method and verification method to berealized in the first application field. In the second field, anoriginal document management method and verification method realizingmore effective partial falsification detection with attention beingfocused on “structuring” which is one of the features of XML documentformat.

Firstly, the basic concept (individual basic functions) which is thefirst application field will be described in line with usage scene. Asan example of operation of the present underlying technique 1, first andsecond phases will be described.

<First Phase>

As the first phase, the following usage scene is assumed.

It is assumed that a user utilizes the present system to record/store anagreement document. In the agreement document, a correction may be madeafter the creation thereof in some cases. In this case, validity such asidentification of corrector, identification of corrected part, orcorrected content is required. The user uses the present system topreserve the records so that he or she can exhibit the records asevidence if embroiled in court case afterward. “Hanako Suzuki” and“Administrator” appear on this scene. Hanako Suzuki newly creates theagreement document and makes a correction for the document.Administrator uses the present system to perform verification. The abovetwo characters are assumed to perform the following processes.

(Creation of New Document)

Hanako Suzuki newly creates a new agreement document and registers it inthe system.

(Correction)

A correction event occurs in the address of Hanako Suzuki due torelocation. Hanako Suzuki herself changes “Kawasaki-shi Nakahara-ku”listed in address field in the agreement document to “Yokohama-shiKohoku-ku” and registers the new address in the system.

(Verification)

Immediately after completion of the correction and registration,administrator performs verification (identification of corrected part,confirmation of corrected content, and confirmation of absence ofcorrection in any other part than the corrected part) involved in theaddress change.

In the above usage scene, the system provides the following threefunctions to Hanako Suzuki and administrator.

(A) New data registration function (this function is used when a newagreement document is created).

(B) Registration data correction function (this function is used when acorrection is made for the agreement document).

(C) Registration data verification function (this function is used whenthe agreement document is verified).

Hereinafter, operations in the above respective events (A) to (C) willbe described.

As a precondition in this usage scene, a user 90 (Hanako Suzuki oradministrator) has previously been registered in this digital documentmanagement system so as to be able to access the system. The usage sceneis started when Hanako Suzuki and administrator access/login the system.Further, it is assumed that policy information corresponding to theagreement document has already been registered and stored in the policystorage section 31. FIG. 3 shows an example of the policy information.

As shown in FIG. 3, the control information written in the policyinformation defines as follows: to input “Name”, “Address”, and “Birthdate” as essential information for the agreement document; “Name” and“Address” can be corrected as needed; “Birth date” is not correctable byits nature; and sanitizing can be applied to “Birth date”. The policyinformation is distributed among a plurality of entities in the system.In view of this, a signature of administrator may be appended to thepolicy information for improvement of its safety.

(A) Creation time of new agreement document

FIG. 6 is a flowchart showing operation of new document registrationprocessing. In this new document registration processing, the user 90(Hanako Suzuki) selects “agreement document” from “creation of newdocument” menu on a not shown window and performs input operation to anagreement document formatted based on the policy information. Aftercompletion of the input operation, a new document registration requestis issued to the request analysis section 20 in the digital documentmanagement system 10. Then, the following steps are performed.

(1) The request analysis section 20 of the digital document managementsystem 10 receives the new document registration request (step ST-R1)and issues the same to the original document processing section 41 (stepST-R2).

(2) The original document processing section 41 issues a registrationpolicy verification request to the registration policy verificationsection 32 a (step ST-R3).

(3) The registration policy verification section 32 a refers to thepolicy information that has already been registered/stored in the policystorage section 31 to verify whether the document has been createdproperly according to the policy information and returns a result of theverification to the original document processing section 41 (stepST-R4).

(4) The original document processing section 41 acquires theverification result from the registration policy verification section 32a. When the verification result is affirmative (OK), the originaldocument processing section 41 issues a partial identificationinformation generation request to the partial identification informationgeneration section 51 (step ST-R5). On the other hand, when theverification result is negative (NG), the user 90 logs out of the systemto abort this new document registration processing.

(5) The partial identification information generation section 51generates partial identification information corresponding to thedocument and returns the generated result to the original documentprocessing section 41 (step ST-R6).

FIG. 4 is a view showing an example of partial identificationinformation generated by the partial identification informationgeneration section 51. In FIG. 4, random number “123” is assigned to acharacter string “Hanako Suzuki”, hash information corresponding to thecharacter string “Hanako Suzuki 123” is calculated, and hash information“abcdefgh” is output as a result of the calculation. The same hashinformation generation processing is applied to other elements.

The reason for using the random number in FIG. 4 is to make it difficultto guess sanitized original information in the case where partialsanitizing is applied in the second phase to be described later.Although the random number is used in the example of FIG. 4, it ispossible to use other techniques for achieving this object.

For example, time stamp F(time-stamp) representing date and time can beused in place of the random number. In this case, F is an arbitraryfunction and time stamp (time-stamp) is not directly applied. This isbecause it is likely that the time stamp may be constituted by a fixedformat such as “year-month-day-time-minute-second” and, therefore, mayeasily be guessed. A use of the time stamp here can also assure creationdata and time.

(6) The original document processing section 41 acquires the partialidentification information from the partial identification informationgeneration section 51 and registers/stores the agreement document andpartial identification information in the original document storagesection 42 (step ST-R7).

At this time, a signature of Hanako Suzuki is appended to the agreementdocument and partial identification information respectively.

FIG. 5 shows a state of the original document storage section 42 at thenew document registration time. As shown in FIG. 5, the generatedpartial identification information is combined with the agreementdocument which is a main body as management information thereof. Aftercompletion of the steps described above, the user 90 logs out of thesystem to normally end the new document registration processing.

(B) Correction Time of Agreement Document

FIG. 10 is a flowchart showing operation of registration documentcorrection processing. When the user 90 (Hanako Suzuki) selects“registration document correction” menu on a not-shown window, “targetregistration document list” representing documents for which HanakoSuzuki can perform processing (i.e., make a correction) is displayed.When Hanako Suzuki selects an agreement document to be corrected fromthe “target registration document list” on the window, a registrationdocument acquisition request is issued to the request analysis section20 of the digital document management system 10. Then, the followingsteps are performed.

(1) When the registration document acquisition request is issued, therequest analysis section 20 of the digital document management system 10receives the registration document acquisition request (step ST-U1) andissues the same to the original document processing section 41 (stepST-U2).

(2) The original document processing section 41 takes out the agreementdocument registered/stored in the original document storage section 42and displays the document on the window so that Hanako Suzuki can referto it (step ST-U3).

When Hanako Suzuki changes “Kawasaki-shi Nakahara-ku” listed in addressfield in the agreement document to “Yokohama-shi Kohoku-ku”, aregistration document correction request is issued to the requestanalysis section 20 of the digital document management system 10.

(3) The request analysis section 20 of the digital document managementsystem 10 receives the registration document correction request (stepST-U4) and issues the same to the original document processing section41 (step ST-U5).

(4) The original document processing section 41 issues a correctionpolicy verification request to the correction policy verificationsection 32 b (step ST-U6).

(5) The correction policy verification section 32 b refers to the policyinformation registered/stored in the policy storage section 31 to verifywhether the document has been corrected properly according to the policyinformation and returns a result of the verification to the originaldocument processing section 41 (step ST-U7). Note that, the abovecorrection policy verification is performed only for a correctable area(without departing from the correctable area) defined in the originaldocument information.

FIG. 7 is a view showing an example in which a correctable area andnon-correctable area are identified. When a correctable area “address”is corrected, the verification result becomes affirmative (OK). On theother hand, when a non-correctable area “birth date” is corrected, theverification result becomes negative (NG).

(6) The original document processing section 41 acquires a result of theverification from the correction policy verification section 32 b. Whenthe verification result is affirmative, the original document processingsection 41 issues a partial identification information generationrequest to the partial identification information generation section 51(step ST-U8). When the verification result is negative, the user 90 logsout of the system to abort this registration document correctionprocessing.

(7) The partial identification information generation section 51generates partial identification information corresponding to theagreement document and returns the generation result to the originaldocument processing section 41 (step ST-U9). In this partialidentification information generation processing, a new random number ora time stamp indicating the correction processing time is used to newlygenerate partial identification information corresponding to “address”which has been corrected from the previous version. The partialidentification information corresponding to entries other than “address”(corrected part) are generated using the same random number as that usedin the previous version or a time stamp indicating the document creationtime. Thus, it is possible to certify that the corrected document(second version) is derivative of the original document (first version).Further, different partial identification information is generated eachtime even when the same person inputs the same content, so that it ispossible to certify “same handwriting”, in terms of a paper document.

(8) Subsequently, the original document processing section 41 issues apartial correction information generation request to the partialcorrection information generation section 52 (step ST-U10).

(9) The partial correction information generation section 52 generatespartial correction information corresponding to the agreement documentand returns to the generation result to the original document processingsection 41 (step ST-U11). FIG. 8 shows an example of the partialcorrection information.

(10) The original document processing section 41 acquires the partialidentification information and partial correction informationrespectively from the partial identification information generationsection 51 and partial correction information generation section 52 andregisters/stores the corrected agreement document together with thepartial identification information and partial correction information inthe original document storage section 42. At this time, a signature ofHanako Suzuki is appended to the agreement document, the partialidentification information and partial correction informationrespectively (step ST-U12).

FIG. 9 is a view showing a state of the original document storagesection 42 at the registration document correction time. Referring tothe attribute (=R portion) (in this example, random number is used) ofaddress element, it can be seen that different random numbers are usedbetween the first version (R=“234”) and second version (R=“876”). On theother hand, the same random number is used in the fields other than theaddress field between the first and second versions. The same isapparently true in the case of the partial identification information.

After completion of the above steps, the user 90 logs out of the systemto normally end the new document correction processing. At any one ofthe above steps ST-U8 to ST-U11, the digital document management system10 may display a message including “corrected part” and “correctedcontent” to seek consensus on the correction from the user 90 (HanakoSuzuki). For example, a message says “Are you certain that address hasbeen changed from “Kawasaki-shi Nakahara-ku” to “Yokohama-shiKohoku-ku?”.

(C) Integrity/validity verification time of corrected agreement documentFIG. 14 is a flowchart showing operation of registration documentverification processing.

When the user 90 (administrator) selects “registration documentverification” menu on a not-shown window, “target registration documentlist” representing documents for which the administrator can performprocessing (i.e., verification) is displayed. When the administratorselects an agreement document to be verified from the “targetregistration document list” on the window, a registration documentverification request is issued to the request analysis section 20 of thedigital document management system 10. Then, the following steps areperformed.

(1) The request analysis section 20 of the digital document managementsystem 10 receives the registration document verification request (stepST-V1) and issues the same to the original document processing section41 (step ST-V2).

(2) The original document processing section 41 takes out the relevantverification data group registered/stored in the original documentstorage section 42 (step ST-V3). The verification data group to be takenat this time is as follows. The number in the brackets indicates theversion number, where the latest version is set to N-th version.

(a): Agreement Document (latest version: second version [N-th version])

(b): Partial identification information (latest version; second version[N-th version])

(c): Partial identification information (first version [N-1th version])

(d): Partial correction information (latest version: second version[N-th version])

(3) The original document processing section 41 issues a correctionpolicy verification request to the correction policy verificationsection 32 b (step ST-V4).

(4) The correction policy verification section 32 b refers to the policyinformation registered/stored in the policy storage section 31 tocompare the policy information and partial correction information (d)acquired in step ST-V3 to thereby verify whether the document has beencorrected properly according to the policy information and returns aresult of the verification to the original document processing section41 (step ST-V5).

FIG. 11 is a view showing the policy information and partial correctioninformation to be compared at this time. The partial correctioninformation indicates that corrected part is “address”, and the policyinformation indicates that “address” is defined as a correctable area.Therefore, the verification results in affirmation (OK).

(5) The original document processing section 41 acquires theverification result from the correction policy verification section 32b. Subsequently, the original document processing section 41 issues apartial correction information verification request to the partialcorrection information verification section 62 (step ST-V6).

(6) The partial correction information verification section 62 executesthe following verification processing and returns a verification resultto the original document processing section 41 (step ST-V7).

(6-1) Refers to the partial correction information (d) acquired in stepST-V3 to identify a corrected part and confirm partial correctioncontent.

(7) Subsequently, the original document processing section 41 issues apartial identification information verification request to the partialidentification information verification section 61 (step ST-V8).

(8) The partial identification information verification section 61executes the following verification processing and returns averification result to the original document processing section 41 (stepST-V9).

(8-1) Compares the agreement document (a) and partial identificationinformation (b) acquired in step ST-V3 and confirm whether there is nofalsification in them after registering the relevant version ofagreement document in the system. FIG. 12 is a view showing theagreement document and partial identification information to be comparedat this time.

(8-2) Identifies a corrected part (“address”) based on the verificationresult (6-1) of the partial correction information which has beenacquired in step ST-V7; Compares the content of “address” between thepartial identification information (b) and (c) to confirm that acorrection has been made for “address”; Confirms that any other partthan the corrected part has not been corrected from the previousversion. FIG. 13 is a view showing the partial identificationinformation (b) and (c) to be compared. In this example, the partialidentification information verification section 61 confirms that onlyrandom numbers (“67890123” and “qrstuvwx”) assigned to address partdiffer from each other between the first and second versions of partialidentification information. Accordingly, the partial identificationinformation verification section 61 can confirm that any other part thanthe address part has not been corrected from the previous version (firstversion).

(9) The original document processing section 41 collectively outputs theverification results acquired in steps ST-V5, ST-V7, and ST-V9 (stepST-V10).

After completion of the steps described above, the user 90 logs out ofthe system to normally end the registration document verificationprocessing. Note that, in the above configuration, the correction policyverification section 32 b and partial integrity information verificationsection 60 (partial identification information verification section 61and partial correction information verification section 62) constitute aregistration document verification section of the present invention.

<Second Phase>

As the second phase in this underlying technique, the following usagescene is assumed.

In the second phase, a user utilizes the present system to distribute anagreement document that has been corrected and registered in site A tosite B. It is assumed that, during the course of distribution,information of “birth date” is subjected to sanitizing while informationother than “birth date” is disclosed. “Hanako Suzuki” and “Taro sato”and “Minoru Yamada” appear on this scene. Hanako Suzuki newly createdthe agreement document and registered it after making a correction forthe document in the first phase. Taro Sato, who is a transmitter,applies sanitizing to “birth date” field in the agreement document anddistributes the document toward a receiver at site B. Minoru Yamada, whois a receiver, receives a complete set of the agreement documenttransmitted from Taro Sato at site A and registers the document in thesystem at site B. Further, Minoru Yamada acquires verification dataincluding the agreement document distributed from site A for a public athird-party certification (e.g., for exhibiting the data as evidence ina court case). The above three characters are assumed to perform thefollowing four processes.

(Correction (Partial Sanitizing))

Hanako Suzuki, a user located in site A, creates an agreement documentand registered it in the system. After a correction has been made forthe agreement document by Hanako Suzuki, Taro Sato, who is atransmitter, performs correction processing to the document andregisters it in the system existing at site A as preparation fordistribution to site B. In this correction processing, information of“birth date” is subjected to sanitizing while information other than“birth date” is disclosed.

(Distribution (Transmission))

Taro Sato, who is a transmitter located at site A, transmits a completeset of the agreement document to Minoru Yamada who is a receiver locatedat site B.

(Distribution (Reception))

Minoru Yamada, who is a receiver located at site B, receives a completeset of the agreement document transmitted from Taro Sato who is atransmitter located at site A and registers the document in the systemexisting at site B.

(Taking Out for a Third-Party Certification)

Minoru Yamada located at site B takes out a complete set of theagreement document (verification data) transmitted from the site A for apublic third-party certification (e.g., for providing the data asevidence in a court case).

FIG. 15 is a view conceptually showing the usage scene in the secondphase. In the usage scene shown in FIG. 15, the present system providesthe following functions to Taro Sato and Minoru Yamada.

(B) Registration data correction function (this function is used whensanitizing is applied to the agreement document)

(D) Registration data distribution (transmission) function (thisfunction is used when the agreement document is transmitted)

(E) Registration data distribution (reception) function (this functionis used when the agreement document is received)

(F) Registration data acquisition function (this function is used whenthe agreement document is exhibited as evidence in a court case)

The operation of (B) has been described in the usage scene set in thefirst phase and the description thereof is omitted. Hereinafter,operations in the above respective events (D) to (F) will be described.FIG. 16 shows a state of the original document storage section 42 at thecorrection (partial sanitizing) time of (B). It can be seen form FIG. 16that a third version has newly been registered. Further, it can be seenfrom a comparison between the second and third versions of partialidentification information that there is a difference only in theinformation of “birth date” and “profile data” due to sanitizingprocessing applied to “birth date” field. As a precondition in thisusage scene, users 90 (Taro Sato and Minoru Yamada) have previously beenregistered in this digital document integrity assurance system so as tobe able to access the system. The usage scene is started when Taro Satoand Minoru Yamada access/login the system.

(D) Distribution (Transmission) Time of Agreement Document

FIG. 18 is a flowchart showing operation of registration documentdistribution (transmission) processing.

When the user 90 (Taro Sato) selects “registration document distribution(transmission)” menu on a not-shown window, “target registrationdocument list” representing documents for which Taro Sato can performprocessing (i.e., transmission processing) is displayed. When Taro Satoselects an agreement document to be transmitted from the “targetregistration document list” on the window, a registration documentacquisition request is issued to the request analysis section 20 of thedigital document management system 10. Then, the following steps areperformed.

(1) The request analysis section 20 of the digital document managementsystem 10 receives the registration document acquisition request (stepST-S1) and issues the same to the original document processing section41 (step ST-S2).

(2) The original document processing section 41 takes out the agreementdocument set registered/stored in the original document storage section42 and displays the document on the window so that Taro Sato can referto it. Further, the original document processing section 41 takes outthe policy information of the agreement document registered/stored inthe policy storage section 31 (step ST-S3). The agreement document setto be taken out at this time is shown in FIG. 17.

It should be noted that the agreement document—main body (secondversion) is not disclosed. This is because that information before beingsanitized is included in agreement document—main body (second version).Naturally, in the partial sanitizing processing, information beforebeing sanitized is hidden in “information before correction” of thepartial correction information, although this is the same withcorrection processing. By transmitting these information of FIG. 16other than the agreement document—main body (second version) in acombined manner, it is possible to distribute the information to spot Bto allow the user located at site B to utilize the information whilekeeping the content before being sanitized confidential. Further, athird-party certification is made possible. A method of achieving athird-party certification using the document group will be describedlater. After Taro Sato has confirmed the content of the transmitteddocument, a registration document distribution (transmission) request isissued to the request analysis section 20 of the digital documentmanagement system 10.

(3) The request analysis section 20 of the digital document managementsystem 10 receives the registration document distribution (transmission)request (step ST-S4) and issues the same to the original documentprocessing section 41 (step ST-S5).

(4) The original document processing section 41 executes a verificationprocess of the agreement document to be transmitted (step ST-S6). Theverification process performed at this time has been described in theusage scene set in the first phase and the description thereof isomitted.

(5) The original document processing section 41 acquires a verificationresult of the agreement document to be transmitted. When theverification result is affirmative (OK), the original documentprocessing section 41 issues a transmission request to the transmissionprocessing section 71 (step ST-S7). On the other hand, when theverification result is negative (NG), the user 90 logs out of the systemto abort this registration document distribution (transmission)processing.

(6) The transmission processing section 71 transmits the agreementdocument set to the digital document management system located at site Band returns a transmission result to the original document processingsection 41 (step ST-S8).

After completion of the above steps, the user 90 logs out of the systemto normally end the registration document distribution (transmission)processing.

(E) Reception Time of Agreement Document

FIG. 19 is a flowchart showing operation of reception processing of adocument to be registered.

When the user 90 (Minoru Yamada) selects “reception of to-be-registereddocument” menu on a not-shown window, “target to-be-registered documentlist” representing documents for which Minoru Yamada can performprocessing (i.e., reception processing) is displayed. When Minoru Yamadaselects an agreement document to be received from the “targetto-be-registered document list” on the window, a to-be-registereddocument reception request is issued to the request analysis section 20of the digital document management system 10. Then, the following stepsare performed.

(1) The request analysis section 20 of the digital document managementsystem 10 receives the to-be-registered document reception request (stepST-T1) and issues the same to the original document processing section41 (step ST-T2).

(2) The original document processing section 41 issues theto-be-registered document reception request to the reception processingsection 72.

(3) The reception processing section 72 receives the agreement documentset at the present system at site B and returns the received agreementdocument set to the original document processing section 41 (stepST-T3).

(4) The original document processing section 41 executes a verificationprocess of the agreement document acquired from the reception processingsection 72 (step ST-T4). The verification process performed at this timehas been described in the usage scene set in the first phase and thedescription thereof is omitted.

(5) The original document processing section 41 acquires a verificationresult of the agreement document to be received. When the verificationresult is affirmative (OK), the original document processing section 41registers/stores policy information included in the agreement documentset to the policy storage section 31 and registers/stores the agreementdocument set in the original document storage section 42 (step ST-T5).On the other hand, when the verification result is negative (NG), theuser 90 logs out of the system to abort this to-be-registered documentreception processing.

After completion of the above steps, the user 90 logs out of the systemto normally end this to-be-registered document reception processing.

(F) Acquisition Time of Agreement Document

FIG. 20 is a flowchart showing operation of registration documentacquisition processing.

When the user 90 (Minoru Yamada) selects “registration documentacquisition” menu on a not-shown window, “target registration documentlist” representing documents for which Minoru Yamada can performprocessing (i.e., acquisition processing) is displayed. When MinoruYamada selects an agreement document to be acquired from the “targetregistration document list” on the window, a registration documentacquisition request is issued to the request analysis section 20 of thedigital document management system 10. Then, the following steps areperformed.

(1) The request analysis section 20 of the digital document managementsystem 10 receives the registration document acquisition request (stepST-G1) and issues the same to the original document processing section41 (step ST-G2).

(2) The original document processing section 41 acquires the agreementdocument registered/stored in the original document storage section 42.Further, the original document processing section 41 takes out policyinformation of the agreement document registered/stored in the policystorage section 31 (step ST-G3).

After completion of the above steps, the user 90 logs out of the systemto normally end this registration document acquisition processing. FIG.17 shows the verification data group to be taken out by this acquisitionprocessing. A description will be given of what kind of third-partycertifications can be achieved in the present usage scene in the casewhere the verification data group is exhibited in a court or the like asevidence.

Firstly, in FIG. 21, a comparison among the agreement document (thirdversion) (D3), partial identification information (second version) (S2),and partial identification information (third version) (S3) allows thefollowing third-party certifications to be achieved.

Certification 1: Capable of confirming that the agreement document(third version) (D3) is created based on the agreement document signedby Hanako Suzuki.

Certification 2: Capable of confirming that the content described byHanako Suzuki has not been falsified.

Certification 3: Capable of confirming that only “birth date” field hasbeen changed from the previous version. Capable of confirming that anyother part than the “birth date” field have not been changed from theprevious version.

(Verification Method for Certifications 1 to 3)

It can be seen form FIG. 21, the hash value (“yz012345”) of birth datein the partial identification information (second version) (S2) differsfrom that (“qwertyui”) in the partial identification information (thirdversion) (S3) and, accordingly, profile data between the two versionsdiffer from each other. However, the hash values of other partscorrespond to each other between the two versions.

As a result, it is possible to confirm that only “birth date” and“profile data” have been changed between the second and third versions.At the same time, it is possible to confirm that any other part than the“birth date” and “profile data” includes no change. Further, signaturesof Hanako Suzuki and Taro Sato are appended to the partialidentification information (second version) (S2) and partialidentification information (third version) (S3) respectively andverification thereof can be made. Therefore, certification 3 can beverified. Further, it can be seen from the above comparison that asignature of Hanako Suzuki is certainly appended to any other part thanthe changed part. Therefore, the certifications 1 and 2 can be verified.

While “profile data” is included in the partial identificationinformation in the present underlying technique, if the “profile data”is excluded from the partial identification information, the differentportion is confined to “birth date” field.

Next, a comparison between the agreement document (third version) (D3)and partial identification information (third version) (S3) in FIG. 22allows the following third-party certifications to be achieved.

Certification 4: Capable of confirming that the content of the agreementdocument (third version) (D3) has not been falsified since it wasregistered in the system.

(Verification Method for Certification 4)

The certification 4 can be verified by regenerating partialidentification information from the agreement document (third version)(D3) and comparing the agreement document (third version) (D3) andregenerated partial identification information (third version) (S3). Forexample, character strings “Hanako Suzuki” and “123” of the name elementin the agreement document (third version) (D3) are coupled to each otherto generate a character string “Hanako Suzuki 123”. A hash value isgenerated from the character string “Hanako Suzuki 123”. “abcdefgh” isextracted from the name element in the partial identificationinformation (third version) (S3) and the hash value thereof isgenerated. Then, the above two hash values are compared to each other todetermine whether they are identical or not. The same processing andcomparison are applied to any other part than the name element. Onlywhen all elements are determined to be identical between the agreementdocument (third version) (D3) and regenerated partial identificationinformation (third version) (S3), it is possible to say that theagreement document (third version) (D3) has not been falsified since itwas registered in the system. Therefore, the certification 4 can beverified.

Further, a comparison between the agreement document (third version)(D3) and partial correction information (third version) (T3) in FIG. 23allows the following third-party certifications to be achieved.

Certification 5: Capable of confirming that “birth date” of the current(third version (D3)) agreement document has been subjected to sanitizingprocessing in the previous version by referring to the partialcorrection information (third version) (T3).

Capable of confirming the corrected (sanitized) date and time andcorrector's name (in this case, Taro Sato).

(Verification Method for Certification 5)

The certification 5 can be verified by referring to the corrected dateand time, corrector, corrected part, correction code, correction reasonin the partial correction information (third version) (T3) to which asignature of Taro Sato is appended.

(Underlying Technique 2)

Next, as an underlying technique 2 of the present invention, a casewhere the underlying technique of the present invention is applied to asecond application field will be described. As described above, anoriginal document management method and verification method realizingmore effective partial falsification detection in an XML document willbe described below.

In the present usage scene, “insurance application form” is employed asdigital data distributed among three entities (applicant, insurancecompany, and financial institution) to assume “insurance applicationservice” where the data on the “insurance application form” is handled.FIG. 24 is a view showing a form of the present system model. Whenaccessing the “insurance application service” (dedicated Web server/ASP)provided/operated under the above configuration, the three entities canutilize the present system. It is assumed that this “insuranceapplication service” is operated by a reliable third-party organizationand that the “insurance application form” is distributed through thethird-party organization.

In this service, an applicant (Hanako Suzuki) utilizes the presentsystem installed/provided on Internet to make an insurance application,the insurance company receives the application form, and the financialinstitution makes settlement of this agreement. The flow of the documentis shown in the following steps (1) to (5). Note that the applicant(Hanako Suzuki), an insurance company representative, and a financialinstitution representative have already been registered in the“insurance application service”.

(1) The applicant (Hanako Suzuki) logs in (at this time, identificationis made using, e.g., a combination of ID and password or throughbiometrics) the “insurance application service” through a Web browser,creates/registers an insurance application form (first version) tothereby store the application form in an original document storage unit(original document storage section 42) installed in the present system.When the applicant performs e.g., determination key/transmission keydepression operation, application form data (first version) istransmitted to the insurance company (arrow S1 in FIG. 24).

(2) The financial institution representative uses some way (e.g., usinga notification through E-mail, or through periodical order check) toacquire the insurance application form (first version) transmitted fromthe applicant (Hanako Suzuki) from the present system and checks andverifies it.

(3) The insurance company representative transmits credit information tothe financial institution in order to make settlement associated withthe insurance agreement. At this time, hiding (sanitizing) is partiallyapplied to the information other than that the financial institutionneeds as the credit information (e.g., information related to a kind ofinsurances). The insurance company representative then updates theinsurance application form (first version) with a new version (secondversion) of the insurance application form in which the sanitizing hasbeen applied and registers it in the system to thereby store theinsurance application form (second version) in an original documentstorage unit (original document storage section 42). When the insurancecompany representative performs e.g., determination key/transmission keydepression operation, application form data (second version) istransmitted to the financial institution (arrow S2 in FIG. 24).

(4) The insurance company representative uses the same way (i.e., uses,e.g., a notification through E-mail like the insurance companyrepresentative) to acquire the insurance application form (secondversion) transmitted from the insurance company from the present systemand checks and verifies it.

(5) The financial institution representative transmits a settlementresult associated with the insurance agreement between Hanako Suzuki andinsurance company to the insurance company. At this time, the financialinstitution representative adds credit confirmation information to theapplication form data to thereby update it with a new version (thirdversion) of the insurance application form and registers it in thesystem to thereby store the insurance application form (third version)in an original document storage unit (original document storage section42). When the financial institution representative performs e.g.,determination key/transmission key depression operation, applicationform data (third version) is transmitted to the insurance company (arrowS3 in FIG. 24).

Next, a method of managing the insurance application form in therespective original document storage units (original document storagesections 42) in the course of the steps (1) to (5) will be described.Further, a verification method performed in respective time points and athird-party certification achieved by the verification will be describedtogether. The techniques and functions for controlling the presentsystem have concretely been described in the usage scene of the firstapplication field (underlying technique 1) and the description thereofis omitted.

(1) Creation of Insurance Application Form (First Version)

FIG. 25 shows an example of the insurance application form (XML data) tobe newly created in the present step. In the first application fielddescribed in the underlying technique 1, a very simple XML data (seeFIG. 5) having a flat structure (having only one parent element with aplurality of child elements) has been taken as an example for thepurpose of explaining a basic concept. In the second application field,XML data having a complicated hierarchical structure as shown in FIG. 25is used. FIG. 25 is an example in which the main body of the insuranceapplication form (first version) is represented using the XML data.

In the example of XML data shown in FIG. 25, <insurance applicationform> is set as a root element, and three parent elements (<contractor>,<designated account>, and <agreement information>) are located under<insurance application form>. Various child elements are located undereach parent element. FIG. 26 is a tree model of the XML data and showsan XML data model of the insurance application form (first version). Itcan be said that the insurance application form is a kind of ahierarchically structured document having a tree structure.

A generation method of partial identification information correspondingto the insurance application form data will next be described. FIG. 27shows an example in which the partial identification informationgenerated at the creation time of the insurance application form (firstversion) is represented using XML data.

As shown in FIG. 27, in first version, hash information of all childelements, as well as hash information of all parent elements (<insuranceapplication form>, <contractor>, <designated account>, <agreementinformation>, <name>) are generated and recorded.

The above configuration is made for the purpose of simplifying adocument update process to be performed after the first version. Thatis, when no change is made for a set of parent and child elements (e.g.,<family name>, <first name>, <name> (which is the parent element of<family name> and <first name>), <address>, and <telephone number>), itis only necessary to record the hash information (=“7ed6c”) of<contractor> which is the parent element of the above child elements.FIG. 28 is a view showing the XML data model constituted only by a setof “contractor”. The above data record management makes it possible toomit verification of the five elements (<family name>, <first name>,<name> (which is the parent element of <family name> and <first name>),<address>, and <telephone number>). That is, it is only necessary toperform integrity verification for the hash information of <contractor>,afterward.

Therefore, at the next (second version) verification time, it ispossible to reduce data amount and verification cost much more than acase where verification data corresponding to all of (<family name>,<first name>, <name>, <address>, and <telephone number>) are retainedand managed. While it is assumed that all elements names are unique inthis example, there is a possibility that the same element name may beused with different meaning in a different place. It follows that amechanism that uses an Xpath function or the like to identify/manage thehash information of such elements needs to be provided.

(2) Acquisition/Verification of Insurance Application Form (FirstVersion)

FIG. 29 is an original document storage state at the creation time ofthe insurance application form (first version). As shown in FIG. 29, theinsurance company representative acquires the insurance applicationform-main body (first version) and partial identification informationand performs verification. The use of the verification data group allowsthe insurance company representative to confirm whether the insuranceapplication form has been created by the applicant (Hanako Suzuki) andwhether there is no falsification in the allocation form itself. Aconcrete method used in verifying the first version has already beendescribed in the first application field in the underlying technique 1and the description thereof is omitted.

(3) Creation of Insurance Application Form (Second Version)

To create the insurance application form (second version), the insurancecompany representative makes update of the insurance application form(first version) created by the applicant (Hanako Suzuki). As the updateprocess, the insurance company representative performs partial hiding(sanitizing) for the contractor information. FIG. 30 is a view showingan example in which the updated insurance application form-main body(second version) is represented using XML data.

A part TZ in FIG. 30 denotes the part that has been corrected this time.It goes without saying that a digital signature appended to the mainbody at this time is not of the applicant (Hanako Suzuki) but of theinsurance company. In this way, the use of a general digital signaturesystem assures identification (i.e., who has created the document) andintegrity (i.e., document itself has not been falsified).

A characteristic of the underlying technique of the present invention isas follows. For the entire document, a general digital signature systemis used to assure safety. For respective parts in the document, partialidentification information is generated and managed separately from themain body to clarify the responsibility of the partial identificationinformation with respect to “Who has made a correction”, “for which parta correction has been made”, and “how the document has been changed”.

As denoted by the part TZ in FIG. 30, the changed elements are <kind ofinsurance> and <insurance amount> and the changed contents thereof arerepresented by asterisks (*****). This expression section that theinformation corresponding to the changed contents has been hidden(sanitized). As a matter of course, as described in the firstapplication field in the first underlying technique, R-attributes of thechanged elements (<kind of insurance>, <insurance amount>, <agreementinformation> (which is the parent element of <kind of insurance> and<insurance amount>)) have been changed.

Similarly, R-attribute of <insurance application form> which is theparent element of <agreement information> and root element of thepresent XML data has been changed. The reason for appending R-attributein the document and the reason for changing R-attribute corresponding toa changed part have already been described in the abovementioned firstapplication field and the description thereof is omitted.

A method of generating partial identification information correspondingto the insurance application form data (second version) will next bedescribed. FIG. 31 is a view showing an example in which partialidentification information generated at the creation time of theinsurance application form (second version) is represented using XMLdata.

As shown in FIG. 31, the following method is used to generate partialidentification information, as far as the second version and subsequentversions are concerned.

Firstly, in this example, no change has been made for <contractor> and<designated account> which are parent elements. This signifies that nochange has been made for all child elements located under <contractor>and <designated account>. Therefore, only the hash information of theparent elements (<contractor> and <designated account>) are recorded inthe partial identification information (second version), as describedabove (V2-1 in FIG. 31). The relevant part may be copied from thepartial identification information (first version) or may be generatedonce again from the insurance application form-main body (secondversion).

It is obviously adequate to use the former method in the sense ofreducing generation cost of the partial identification information.

The changes of this time in <kind of insurance> and <insurance amount>give influence to the hash information of the parent elements, i.e.,<agreement information> and <insurance application form>. In thisexample, the hash information of the parent elements are generated andrecorded once again (V2-2 in FIG. 31). This part (V2-2) can directly beutilized at the next update (third version) time if there is no changein the relevant part.

With the above configuration, it is possible to reduce generation costof the hash information corresponding to unchanged part in the nextupdate or later. In this example, <insurance application form> serves asa root element. Thus, only one change in the parent/child elements under<insurance application form> causes the hash information of the rootelement (<insurance application form>) to be changed. The recording ofthe hash information of the root element (<insurance application form>)makes it possible to easily confirm that there is no falsification inthe information, improving further the verification quality.

However, since similar verification can be made using a digitalsignature appended to the entire document, it is not always necessary torecord the hash information of the root element (<insurance applicationform>). It goes without saying that it is necessary to regenerate andrecord the hash information corresponding to <kind of insurance> and<insurance amount> which have been changed this time in order toidentify the changed part afterward (V2-3 in FIG. 31).

FIG. 32 is a view showing an original document storage state at thecreation time of the insurance application form (second version). InFIG. 32, a part T1 denotes a changed part, and T2 denotes a part (childelements) which has not been changed this time. It can be seen from thisexample that the hash information corresponding to the child elementsare not recorded but the hash information of the parent elements thereof(<contractor> and <designated account>) are recorded.

The generation/record of the partial correction information has nodirect relevance to the usage scene in the second application field andthe description thereof is not particularly made. A concrete descriptionabout the generation/record of the partial correction information hasbeen made in the usage scene in the first application field.

(4) Acquisition/Verification of Insurance Application Form (SecondVersion)

As shown in FIG. 32, the financial institution representative acquiresthe insurance application form-main body (second version), partialidentification information (second version), and partial identificationinformation (first version). At this time, it is not possible for thefinancial institution representative to acquire/review the insuranceapplication form-main body (first version). This is because that theinsurance application form-main body (first version) has the contents of<kind of insurance> and <insurance amount> before being hidden(sanitized). If these contents are disclosed, it is regarded asinformation leak. Therefore, a mechanism that performs access controlfor respective sites (persons) to limit availability of the documentdepending on the content included at respective time point (versions) isrequired in addition to the original document management method usingversion numbers.

However, this requirement is applicable only in the case wheredistribution data is centrally controlled within an ASP which is one ofthe features of the present usage scene. In a configuration where datais directly exchanged through E-mail or the like, it is only necessaryto simply select/limit transmission data appropriately.

It can be seen that the verification data group that the financialinstitution representative can review under the above condition isconfined to “insurance application form-main body (second version)”,“partial identification information (first version)”, and “partialidentification information (second version)”. FIG. 33 shows theverification data group that the financial institution representativecan review.

A use of the verification data group shown in FIG. 33 allows theverification as described below. Firstly, signatures appended to therespective verification data are verified to confirm/verify whetherrespective verification data themselves include a falsification or not.

After the confirmation that there is no falsification in theverification data, the insurance application form (second version) andpartial identification information (second version) are used to checkthe content of the insurance application form (second version) itselfand check whether there is any replacement of the content. To do this,hash information are generated from the respective elements in theinsurance application form (second version), and the generated hashinformation are compared with the hash information of the correspondingelements recorded in the partial identification information (secondversion) to check whether they are identical to each other.

After the confirmation of the integrity of all elements, a comparisonwith the partial identification information (first version) is made.Since no change has been made for a part OD1 in FIG. 33, the hashinformation of only the parent elements of the child elements existingin the part OD1 are recorded in the partial identification information(second version) as shown by VD1-2. Therefore, when the hash information(VD1-1) in the partial identification information (first version) andhash information (VD1-2) in the partial identification information(second version) are compared with each other, it is possible to confirmthat there is no change in the relevant part.

In this example, the hash information of <contractor> of the partialidentification information (first version) and partial identificationinformation (second version) are “7ed6c”, and hash information of<designated account> thereof are “8c320”, so that it is possible toconfirm that there is no change in <contractor> and <designatedaccount>. Therefore, in this case, it is only necessary to verify theparent element <contractor>. As a result, it is possible to omitverification of five child elements located under <contractor>, i.e.,(<family name>, <first name>, <name> (which is the parent element of<family name> and <first name>), <address>, and <telephone number>) (orfour elements, in the case where the verification of the parent element<name> is not included).

Similarly, it is only necessary to verify the parent element <designatedaccount>. As a result, it is possible to omit verification of threechild elements located under <designated account>, i.e., (<name offinancial institution>, <account number>, and <account holder>). Itfollows that when only two times of verification operations areperformed for the parent element, the same effect as that obtained byeight times of verification operations can be achieved. That is, in thisexample, it is possible to reduce verification cost by 75%. Further,when only two elements are recorded, the same effect as that obtained byrecording of the hash information corresponding to eight elements. As aresult, it is also possible to reduce data amount by 75%.

On the other hand, since a part OD2 in FIG. 33 has been changed from theprevious version, the hash information of the corresponding childelements are recorded in the partial identification information (secondversion), as shown in a part VD2-2. Accordingly, by comparing the hashinformation (VD2-1) in the partial identification information (firstversion) and hash information (VD2-2) in the partial identificationinformation (second version), it is possible to confirm that therelevant part has been changed.

In this example, the hash information of <kind of insurance> differsbetween first version (“abfd3”) and second version (“d2419”). Further,the hash information of <insurance amount> differs between first version(“623a1”) and second version (“f56da”). Accordingly, it is possible toconfirm that the relevant part has been changed.

(5) Creation of Insurance Application Form (Third Version)

To create the insurance application form (third version), the financialinstitution representative makes update of the insurance applicationform (second version) created by the insurance company representative.As the update process, the financial institution representative addscredit confirmation information to the insurance application form.

FIG. 34 is a view showing an example in which the updated insuranceapplication form-main body (third version) is represented using XMLdata. In FIG. 34, a part KZ has been added this time. A digitalsignature appended to the main body at this time is not of the insurancecompany representative but of the financial institution representative.

As denoted by the KZ part in FIG. 34, the added elements are <creditresult> and <credit NO>.

A method of generating partial identification information correspondingto the insurance application form data (third version) will next bedescribed. FIG. 35 is a view showing an example in which partialidentification information generated at the creation time of theinsurance application form (third version) is represented using XMLdata.

As shown in FIG. 35, the following method is used to generate partialidentification information (third version), as in the case with secondversion.

Firstly, in this example, no change has been made for <contractor>,<designated account>, and <agreement information> which are parentelements.

This signifies that no change has been made for all child elementslocated under 10<contractor>, <designated account>, and <agreementinformation>. Therefore, only the hash information of the parentelements (<contractor>, <designated account>, and <agreementinformation>) are recorded in the partial identification information(third version), as described above (V3-1 in FIG. 35).

While <kind of insurance> and <insurance amount> which are childelements located under <agreement information> were changed in theprevious (second version) update time, no change has been made for <kindof insurance> and <insurance amount> this time. It can be easily seenthat the previous recording of the hash information of <agreementinformation> corresponding to the second version of the insuranceapplication form in the partial identification information (secondversion) is effectively utilized at the time of creation of thirdversion. This signifies that the idea “it is possible to reducegeneration cost of the hash information corresponding to unchanged partin the next update or later”, which has been estimated at the creationtime of the partial identification information (second version), hasbeen realized.

According to the above idea, the hash information of <financial creditinformation> which is the parent element of a newly added <creditresult> and <credit NO> (V3-2 in FIG. 35). This part (V3-2) can directlybe utilized at the next update (fourth version) time if there is nochange in the relevant part.

In association with the addition, <insurance application form> which isthe root element is inevitably regenerated and recorded (V3-2 in FIG.35). It goes without saying that it is necessary to regenerate andrecord the hash information corresponding to <credit result> and <creditNO> which have been added this time in order to identify the changedpart afterward (V3-3 in FIG. 35).

FIG. 36 is a view showing an original document storage state at thecreation time of the insurance application form (third version). In FIG.36, a part K1 denotes a part that has newly been added this time, and apart K2 denotes a part (child elements) which has not been changed thistime. It can be seen from this example that the hash informationcorresponding to the child elements are not recorded but the hashinformation of the parent element thereof (<agreement information>) isrecorded.

In the above description, a method of managing the insurance applicationform in the respective original document storage units (originaldocument storage sections 42) in the course of the steps (1) to (5), averification method performed in respective time points, and athird-party certification achieved by the verification have been shown.By performing, at each document creation/update time, the generationmethod of the partial identification information, original documentmanagement method, and verification method shown in steps (1) to (5), itis possible to easily realize the partial falsification detectionfunction of the XML data having a complicated structure. Thus, thepresent system utilizing the partial falsification detection function ofthe XML data has a greater advantage than a system that manages all thechild elements each update time irrespective of presence/absence of achange because it is possible to expect a significant reduction ofverification cost and a reduction of amount of data to betransferred/stored.

Further, the system that manages all the child elements each update timeirrespective of presence/absence of a change can only be utilized forverification between two versions. For example, in the case where thethird version is presented for a third-party's certification, only adifference between the third version and the immediately previousversion (second version) can be verified. Of course, it is possible toverify a change from the first version. In this case, however, partialidentification information including all elements needs to be presented,increasing the amount of data to be transferred/stored and verificationtime.

On the other hand, a use of the partial falsification detection functionof the XML data having a complicated hierarchical structure reduces thedata amount of the partial identification information to berecorded/managed to a minimum level required for verification. That is,it becomes possible to distribute/verify a combination of respectiveversions of partial identification information (first version (original(or base)), second version, third version . . . N-th version) with aminimum amount of data to be transferred/stored. As a result, it ispossible to perform, at each entity (site), historical management ofcorrection events in all versions more simply and at lower cost.

Further, history trace/certification about “When, by whom, for whichpart, and how a correction has been made” can be achieved.

Although the partial identification information of respective versionsare managed as individual files as shown in the example (FIG. 36) of astorage state of the insurance application form (third version), theymay be coupled to each other and organized in one file. In this case, bycarrying the verification data group among a plurality of entities, thehistory trace/certification can be performed more effectively at eachentity.

Such partial identification information managed in a coupled mannerrequires assurance of time-variant in version numbers and needs to becapable of identifying creators (identification) for each version. AnXlink function may be used to realize the coupling-management method.

FIGS. 37 and 38 show a state where the respective documents are coupledtogether as one file. FIG. 37 shows a state where all the partialidentification information required for verifying the second versionhave been coupled together, and FIG. 38 shows a state where all thepartial identification information required for verifying the thirdversion have been coupled together.

A digital signature of the creator is appended to each version of thepartial identification information. A use of an XML partial digitalsignature or the like makes it possible to easily append the digitalsignature. In the present usage scene, a signature of the applicant(Hanako Suzuki) has been appended to the first version, a signature ofthe insurance company representative has been appended to the secondversion, and a signature of the financial institution representative hasbeen appended to the third version. Therefore, identification andintegrity of the data itself can be easily verified in the respectivepartial identification information.

It can be seen from a comparison between FIG. 37 and FIG. 38, simply byperforming historical management in the form of the partialidentification information, a partially corrected part and correctedcontent can independently be certificate in a third-party manner even ifthe main body of the insurance application form is overwritten. In otherwords, it can be said that the content of the partial identificationinformation is a snapshot of each version. By carrying the verificationdata group having the form described above among a plurality ofentities, it is possible to easily perform the historicaltrace/certification for each part of the document at each site whilepreventing leakage of information that has partially been hidden.

Described in the above usage scene is a method (hereinafter, referred toas “method 1”) that records child elements and its parent element for apart that has been corrected from the previous version but records onlya parent element for a part where all child elements located under theparent element have not been corrected.

In addition to the method 1, there is available a method that recordschild elements and its parent element only for a part that has beencorrected from the previous version, that is, purely manages only adifference in order to reduce the amount of data to betransferred/stored more than the method 1. In the following, this method(referred to as “method 2”) that manages only a difference will bedescribed.

According to the method 1, a management method of the partialidentification information of the insurance application form-main body(second version) (FIG. 30) is represented as shown in FIG. 31. Accordingto the method 2, the management method thereof is represented as shownin FIG. 39. FIG. 39 is a view showing an example in which the method 2is used to represent the partial identification information (secondversion) using XML data.

In the method 2, as shown in FIG. 39, unchanged part (<contractor> and<designated account>), which has been recorded in the method 1, is notrecorded. Thus, the amount of data to be transferred/stored can bereduced more than in the case of the method 1.

FIG. 40 shows an original document storage state at the creation time ofthe insurance application form (third version) in the method 2.

Next, cost evaluation/analysis is made for the amount of data to betransferred/stored and verification processing associated with thegeneration of the partial identification information with respect to thefollowing three methods. A method 0 indicates a method that has beendescribed in the usage scene in the first application field.

The method 0 (comparison target) records all the hash informationirrespective of presence/absence of a change. The method 1 records childelements and its parent element for a part that has been corrected fromthe previous version but records only a parent element for a part whereall child elements located under the parent element have not beencorrected (this method has been adopted in the usage scene of the secondapplication field). The method 2 records child elements and its parentelement only for a part that has been corrected from the previousversion, that is, purely manages only a difference.

Simple XML data as shown in FIG. 41 is used to perform analysis. FIG. 41is a view showing an example of XML data for evaluation/analysis.

It is assumed, in the present evaluation/analysis, that only <kind ofinsurance> is subjected to correction at the update time to the secondversion. FIG. 42 shows a state where the content of <kind of insurance>is changed from “AA” to “BBB”. That is, FIG. 42 is a view showing theupdate of XML data for evaluation/analysis.

Firstly, the analysis is made for the amount of data to betransferred/stored and the number of verification operations withrespect to the comparison target (method 0). FIG. 43 shows a datamanagement method and verification processing in the method 0. That is,FIG. 43 is a view showing generation and verification of the partialidentification information according to the method 0. In verificationA1, the insurance application form (second version) and partialidentification information (second version) are used to check whetherthe content of the insurance application form (second version) has beenpartly changed. To do this, the hash information are generated fromrespective elements in the insurance application form (second version)and compared with the has information of the corresponding elementsrecorded in the partial identification information (second version) todetermine the identity between them.

In verification A2, a comparison between the partial identificationinformation (second version) and its previous version (first version) ofthe partial identification information is made to identify a changedpart and confirm that any other part than the changed part includes nochange.

The amount of data to be transferred/stored and the number ofverification operations in the method 0 are summarized as follows. Thetransfer/storage data of the partial identification information (secondversion) is 7 lines, in terms of the number of lines.

Since all the hash information corresponding to the changed andunchanged elements are recorded in the method 0, the data amountcorresponding to 7 lines are recorded both in the first and secondversions respectively. Note that an element <partial identificationinformation>, which is a root element, is not counted in this example.As for the verification cost, 7 times of verification operations areperformed in verification A1 and 7 times of verification operations areperformed in verification A2, resulting in generation of costcorresponding to 14 times of verification operations.

Secondly, the analysis is made for the amount of data to betransferred/stored and the number of verification operations withrespect to the method 1. FIG. 44 shows a data management method andverification processing in the method 1. That is, FIG. 44 is a viewshowing generation and verification of the partial identificationinformation according to the method 1.

The amount of data to be transferred/stored and the number ofverification operations in the method 1 are summarized as follows. Thetransfer/storage data of the partial identification information (secondversion) is 3 lines. Since the method 1 records child elements and itsparent element only for a part that has been corrected from the previousversion but records only a parent element for a part where all childelements located under the parent element have not been corrected, thedata amount of each of the first and second versions can be reduced ascompared with that in the method 0.

As for the verification cost, 3 times of verification operations areperformed in verification B1 and 3 times of verification operations areperformed in verification B2, resulting in generation of costcorresponding to 6 times of verification operations.

That is, one verification operation for <contractor> corresponds toverification operations for four elements (<name>, <family name>, <firstname>, and <address>), so that the number of verification operations canbe correspondingly reduced.

Thirdly, the analysis is made for the amount of data to betransferred/stored and the number of verification operations withrespect to the method 2. FIG. 45 shows a data management method andverification processing in the method 2. That is, FIG. 45 is a viewshowing generation and verification of the partial identificationinformation according to the method 2.

The amount of data to be transferred/stored and the number ofverification operations in the method 2 are summarized as follows. Thetransfer/storage data of the partial identification information (secondversion) is 2 lines. Since the method 2 records child elements and itsparent element only for a part that has been corrected from the previousversion, the data amount of each of the first and second versions can bereduced as compared with that in the method 0, as in the case of themethod 1.

As for the verification cost, 2 times of verification operations areperformed in verification C1 and 2 times of verification operations areperformed in verification C2, resulting in generation of costcorresponding to 4 times of verification operations.

The method 2 cannot verify that <contractor>, <name>, <family name>,<first name>, and <address> which correspond to an unchanged part havenot been changed from the previous version, since, in verification C1,the insurance application form (second version) and partialidentification information (second version) are used to check thecontent of the insurance application form (second version) itself andcheck whether there is any replacement of the content. That is, themethod 2 places utmost priority on the transfer/storage data amount andtherefore does not have information for verifying that point.

Accordingly, it is necessary to generate the hash information of therelevant elements based on the insurance application form (secondversion) and compares the hash information thereof with those of thecorresponding elements in the previous version (first version) of thepartial identification information. This verification is performed asverification C3 in FIG. 45. In this step, cost corresponding to 5 timesof verification operations is generated. In total, cost corresponding to9 times (=2 (C1)+2 (C2)+5 (C3)) of verification operations is generated.

A comparison between methods 1 and 2 is made with respect to theanalysis result obtained in the method 0. FIG. 46 shows a result of themethod-based analysis. It can be seen from the analysis result that boththe transfer/storage data amount and the number of verificationoperations are reduced in the methods 1 and 2 respectively as comparedwith the case of the method 0. Therefore, it can be said that it ispreferable to use the method 1 or method 2 for generation/management ofthe partial identification information. Further, it can be seen from acomparison between methods 1 and 2 that although the method 2 needs lesstransfer/storage data amount than the method 1, it needs much time forverification processing, and that the method 1 realizes cost reductionof the transfer/storage data amount and the number of verificationoperations in a balanced manner.

The above result reveals not the order of superiority between themethods 1 and 2, but that it is necessary to select a suitable methoddepending on the degree of the hierarchical structure of the document.

FIG. 47 shows a bubble chart representing the result of the method-basedanalysis.

As described above, according to the underlying technique of the presentinvention, it is possible to satisfy the following requirements whichcannot be met by conventional techniques and a plain combinationthereof. (1) Capable of identify a corrected part in the digitaldocument as well as confirming that any other part than the correctedpart includes no change. (2) Capable of assuring (third-partycertification) the integrity and authenticity of the digital document ateach time point in the case where a corrected digital document isdistributed between a plurality of entities and a correction/addition ismade for the digital document at the respective entities. (3) Capable ofperforming a third-party certification and distribution using a digitaldocument that has been subjected to sanitizing or using only someversions even though all the versions of the digital documentstored/managed in the present system are not taken out.

While the underlying technique of the present invention has beendescribed with respect to management of the original documentinformation of document such as the agreement document, the presentunderlying technique can widely be applied to legal certification,verification, and the like of the history of the document. Further,while the same policy information is used in the verification forregistration and verification for correction, it goes without sayingthat different policy information may be used for the respectiveverification processing.

(Summary of Underlying Technique)

In an embodiment of the present invention, a modified technique forfurther reducing the storage data amount relative to the techniques thathave been described in the underlying techniques 1 and 2 will bedescribed. For convenience of that description, the underlyingtechniques 1 and 2 are summarized below. Note that, in the followingdescription, a sanitizing signature technique in the underlyingtechnique and the embodiment of the present invention is referred to asPIAT signature technique.

In the process of the PIAT signature, three entities: a signer, asanitizer, and verifier appear. The signer generates a signature to beappended to an original document. The sanitizer defines a documentincluding a nondisclosure part based on the original (or sanitized)document to create a sanitized document. The verifier performs signatureverification to confirm the integrity of a disclosure part.

In the underlying technique 1, a document is divided into blocks, andthe hash function is used to extract characteristic information fromeach block. The information obtained by collecting the characteristicinformation is referred to as partial identification information. Adigital signature is appended to the partial identification information.The obtained partial identification information is defined as the firstversion.

In information addition/correction/deletion (sanitizing) for the firstversion, after completion of the informationaddition/correction/deletion (sanitizing), corresponding partialidentification information and a digital signature to be appendedthereto are generated as is the case with processing at the signaturecreation time. Further, information indicating by whom and for whichpart the change has been made is stored as the partial identificationinformation. The obtained partial identification information is definedas the second version.

In the PIAT signature confirmation process, the partial identificationinformation (first version), main document (second version), partialidentification information (second version), and partial correctioninformation (second version) are used to perform verification. Acomparison between the partial identification information (firstversion) and partial identification information (second version) makesit possible to identify a changed part between them. Further, based onthe digital signature appended to the partial identificationinformation, the integrity of the partial identification information canbe verified, as well as identification of the person who creates/changesthe partial identification information can be assured. In addition, theintegrity of the document can be verified/assured based on the documentand partial identification information.

The underlying technique 2 is a modification of the underlying technique1. In the underlying technique 1, since the hash value of all the blocksneeds to be retained as the partial identification information in eachversion, the information amount of the partial identificationinformation becomes enormous. In the underlying technique 2, only achanged part is stored for the second version and subsequent versions ofpartial identification information to thereby reduce the informationamount of the partial identification information. Further, in the casewhere a structured document such as XML structured-document is used,there is proposed a method for effectively store a changed part withattention being focused on its structure.

It is assumed in the above underlying techniques that a document towhich a signature is appended is data messages (M1, . . . Mn) eachincluding n partial document. Further, it is assumed that a randomnumber is generated an appropriate (pseudo) random number generator andthat a function H( ) is a safe arbitrary hash function. Furthermore, itis assumed that a function Sign_(s)k( ) is a safe (i.e., existentiallyunforgeable against adaptive chosen message attacks) arbitrary signaturegeneration function of a signature system.

The overview of the PIAT signature processing in the underlyingtechnique 1 is shown below (Algorithm 1). It is assumed that the numberof sanitizers is m. The sanitizer in the PIAT signaturegenerates/outputs signature σ(0) for a set (the set is referred to aspartial identification information) h(0) of hash values of therespective partial document appended by the random number. A firstsanitizer which has received an original document and a pair of partialidentification information and signature retains the content of apartial document to be disclosed without change and, at the same time,substitutes a random number corresponding to the undisclosed partialdocument with an adequate data message (e.g., M=“XXXX”) and a new randomnumber to obtain a new hash value.

New partial identification information h(1) and signature σ(1) of thesanitizer are generated in this manner, and a sanitized document afterbeing changed and two partial identification information/signature pairs(h(0), σ(0)), (h(1), σ(1)) are output. The sanitizer can identify thepartial document that has been sanitized by comparing the above partialidentification information constituting each pair.

Similarly, j-th (j=1, . . . m) sanitizer receives, as input information,the sanitized document output from the (j−1)-th sanitizer and j partialidentification information/signature pairs (h(0), σ(0), . . . , (h(j−1),σ(j−1)). In this case, the j-th sanitizer can identify the sanitizedpartial document by comparing the partial identification informationh(0) and h(j−1). Subsequently, new partial identification informationand signature (h(j), σ(j) are generated, and a sanitized document afterbeing changed and (j+1) partial identification information/signaturepairs (h(0), a(0)), . . . , (h(j−1), σ(j−1)), (h(j), σ(j)) are output(FIG. 48).

The verifier receives the sanitized document [M(m)] and (m+1) partialidentification information/signature pairs (h(0, σ(0)), . . . , (h(m),σ(m)) output from the last (m-th) sanitizer. The verifier verifies thesanitized document and respective signatures to confirm the integrity ofthe sanitized document and partial identification information. Then theverifier compares the partial identification information h(0) and h(m)to identify the sanitized partial document and, after that, calculates avalue j that satisfies hi(0)= . . . =hi(j−1)≠hi(j)= . . . =hi(m) for thesanitized partial document. When the value j can be obtained, it ispossible to identify that the partial document has been sanitized byj-th sanitizer. When the value j cannot be obtained, it is possible toidentify that an illegal sanitizing has been made as well as by whom theillegal sanitizing has been made.

(Algorithm 1)

(Signature by Signer)

(S1) Original documents (agreement document) (M1, . . . , Mn) are input.

(S2) Randomly generates identifiers ri corresponding to respectivepartial document Mi (i=1, . . . , n) to satisfy [Mi](0)←ri∥Mi; andcalculates hash value hi(0)<H([Mi](0)).

(S3) Generates signature σ(0)←Sign_(sk0)(h(0)) (sk0 is private key ofsigner), where h(0)=h1(0)∥ . . . ∥hn(0).

(S4) Outputs document ([M1](0), . . . , [Mn](0)), partial identificationinformation/signature pair (h(0), σ(0)).

(Sanitizing by j-th Sanitizer)

(S1) Receives document ([M1](j−1), . . . , [Mn](j−1)) and j partialidentification information/signature pairs (h(0), a(0)), . . . ,(h(j−1), σ(j−1)).

(S2) Compares two partial identification information h(0) and h(j−1) toobtain index set C (={i|hi(0)≠hi(j−1)}) of sanitized partial document.

(S3) Defines partial document to be sanitized (to be undisclosed) toobtain index set C⊃C.

(S4) Generates new partial document from respective partial documents[Mi](j−1) (i=1, . . . , n). $\begin{matrix}{{\lbrack{Mi}\rbrack(j)} = \left. r||{{M\quad{if}\quad i} \in {C^{\prime}/C}} \right.} \\{= {\lbrack{Mi}\rbrack\left( {j - 1} \right)\quad{otherwise}}}\end{matrix}$

where, r is random number, and M is adequate data massage.

(S5) Calculates hash value hi(j)←H([Mi](j)) from obtained partialdocument.

(S6) Generates signature σ(j)←Sign_(skj)(h(j)), where skj is private keyof j-th sanitizer, and h(j)=h1(j)∥ . . . hn(j).

(S7) Outputs document ([M1](j), . . . , [Mn](j)) and j+1 partialidentification information/signature pairs (h(0), σ(0), . . . , (h(j),σ(j))).

(Verifier)

(S1) Receives document ([M1](m), . . . , [Mn](m)), m+1 partialidentification information/signature pairs (h(0), σ(0)), . . . , (h(m),σ(m)), and public keys pkj (j=0, . . . , m) of signer/sanitizer.

(S2: Confirmation of sanitized document) Calculates hash values hi ofrespective partial document [Mi](m)(i=1, . . . , n); and outputs invalidif ∥ . . . ∥ hn is not equal to h(m) to end verification.

(S3: Verification of signature) Uses public key pkj and partialidentification information h(j) for respective j (j=0, 0, . . . , m) toverify signature σ(j); and outputs invalid if verification fails to endverification.

(S4: Identification of sanitized part) Compares two partialidentification information h(0) and h(m) to obtain index setC=[i|hi(0)≠hi(m)] of sanitized partial document.

(S5: Verification of sanitizer) Uses m+1 partial identificationinformation h(0), . . . , h(m) to identify sanitizer of i-th (iεC)sanitized partial document; determines that j-th sanitizer has sanitizedabove partial document when hi(0)= . . . =hi(j−1)≠hi(j)= . . . =hi(m) issatisfied; and outputs valid when sanitizers corresponding to all IεCcan be identified and otherwise outputs invalid to end verification.

In (algorithm 1) of the PIAT signature in the underlying technique 1,m+1 partial identification information/signature pairs and, inparticular, (m+1)n hash values (or mn hash values, in the case where thepartial identification information of the last sanitizer is deleted) arerequired in addition to a sanitized document in order to performverification.

However, since most of the m+1 hash values hi(0), . . . , hi(m)corresponding to i-th partial document have the same value (hi(0)= . . .=hi(m) is satisfied in the case where the partial document is disclosed;and hi(0)= . . . =hi(j−1)≠hi(j)= . . . hi(m) is satisfied in the casewhere it is undisclosed), it is inefficient to retain all the hashvalues. In order to cope with this, the underlying technique proposes amodified method that outputs all partial identification informationcorresponding to original documents created by a singer but outputs onlycorrection (sanitizing) information (i, j) of a corrected part when acorrection (sanitizing) has been made. The sanitizing information (i, j)indicates that i-th partial document has been sanitized by j-thsanitizer (FIG. 49).

When the sanitizer makes a correction, a sanitized document after beingchanged, sanitizing information, and a signature to be appended to thesanitizing information are output. The verifier can constituteinformation equivalent to that obtained in the underlying technique 1based on these information, the same processing as conventionallyperformed is effective. Such a modification allows the number of hashvalues required for the verifier to be reduced to n (however, the numberof signatures required is not changed). The underlying technique 1performs version-management of a difference with the first version setas a base point, so that it is called, as a matter of convenience, SCCS(SourceCode Control System) named after a source code management toolthat performs the similar version-management of a difference.

EMBODIMENT

In the present embodiment, a method which is a modification of theunderlying technique 2 and which significantly reduces the informationamount of partial identification information to be retained will bedescribed. That is, although the underlying technique 2 manages adifference between a plurality of versions of partial identificationinformation to thereby reduce the amount of information to be stored,this management technique produces improvement on the reduction of theinformation amount of the second version and subsequent versions of thepartial identification information. In other words, it has not yet beenpossible to reduce the information amount of the first version of thepartial identification information. Further, a signature needs to beappended to each version of the partial identification information and,accordingly, it is necessary to store the digital signature havinginformation amount corresponding to the number of versions. Therefore,an object of the present embodiment is to reduce the information amountof the partial identification information and digital signature as muchas possible.

The underlying technique 1 stores partial identification information(first version) and uses a difference caused in the first version tocreate partial identification information (second version) (forwarddifference). On the other hand, the present embodiment uses a backwarddifference approach where version-management of a difference isperformed with the latest version set as a base point. Basically, thereis no difference in the information amount between the forwarddifference approach and backward difference approach. However, in PIATsignature, the latest partial identification information can begenerated from a main body to be disclosed, eliminating the need tostore the latest version of partial identification information.

A use of the above feature eliminates the need to store partialidentification information serving as a base of a forward differenceapproach (i.e., first version of partial identification information),allowing significant reduction of storage information amount.

Further, while a digital signature needs to be appended to respectiveversions of partial identification information (or a difference betweenthem), the present embodiment will also refer to a case where anAggregate signature scheme is applied to the digital signature system.

First Embodiment

In the first embodiment, a difference management system that manages adifference with the latest version set as a base point is used in placeof the underlying technique 2 (SCCS type difference management system)for the purpose of reducing the information amount of partialidentification information under the use of PIAT signature. This systemis referred to as RCS (Revision Control system) type (modification 1)named after a source code management tool that implements the similarversion-management of a difference.

FIG. 50 shows a configuration of the first embodiment. A digitalsignature creation section 80A is newly added to the configuration usedin the underlying technique 1. Further, the original document managementsection 40, original document processing section 41, and originaldocument storage section 42 are replaced by a document informationmanagement section 40A, processing section 41A, and storage section 42Arespectively. In the following, operation of the first embodiment willbe described.

(Operation of Signature Processing)

FIG. 51 shows operation of signature processing.

(S1) The partial identification information generation section 51divides a message (agreement document) M (0) input by a signer into M1to Mn.

(S2) The partial identification information generation section 51calculates the hashes of respective blocks to generate hash values (forexample, generates h(Mi) for i-th block) to obtain hash value set H(0)

(S3) At the time when a signer performs a signature process, the digitalsignature creation section 80A uses a signature function in which thehash value set H(0) and the private key of the signer are set asparameters to create a digital signature.

The signature created is, for example, Sig₀=Sig(sk0,h(H(0))). Thissignifies that the hash value set is hushed once again, and the privatekey sk0 of the signer is used to append a signature to the resultanthush value set according to signature function Sig( ).

(S4) The document information management section 40A discloses themessage M(0) and signature Sig0 to a sanitizer according to aninstruction of the signer.

Note that while the hush value set is hashed once again in the casewhere a signature function is used in (S3), this is just an example, andit goes without saying that various processing methods may be adopteddepending on the type of signature functions.

(Operation of Sanitizing Processing (1))

FIG. 52 is a view showing operation of the first sanitizing processing(1) applied to an original. The first sanitizing (change processing)processing is as follows.

(S1) The processing section 41A substitutes a message to be undisclosed(changed) with a new message according to an instruction of a sanitizer1. In FIG. 52, messages of blocks 3 and 5 are changed from M3, M5 to S3,S5 respectively. S3 and S5 may be random information or distinctcharacter such as XXXXXXXX that can be recognized as sanitized one onsight. In the case of a change, S3 and S5 are set as information afterchange. A set of the data after change is referred to as M(1).

(S2) The partial identification information generation section 51calculates the hush values (h(M3), h(M5)) of the message blocks (M3 andM5) before change separately according to an instruction of thesanitizer 1. These hush values are called signature restoration data. Asis the case with the signature processing, the hush values arecalculated for respective blocks of M(1) to obtain hash value set H(1).

(S3) The digital signature creation section 80A uses the private key ofthe sanitizer 1 to append a signature to the hush value set H(1)according to an instruction of the sanitizer 1. The signature createdis, for example, Sig₁=Sig(sk₁,h(H(1))). This signifies that the hashvalue set is hushed once again, and the private key sk₁ of the sanitizer1 is used to append a signature to the resultant hush value setaccording to signature function Sig( ).

(S4) The document information management section 40A discloses themessage M(1) and signature Sig₁ as well as the signature Sig₀ of thesigner and signature restoration data to a subsequent sanitizeraccording to an instruction of the sanitizer 1. While the signaturerestoration data discloses the ID (which identifies that the sanitizeris the first sanitizer) of the sanitizer 1 and block number of themessage corresponding to the signature restoration data together, anyformat may be used to disclose the signature restoration data as far asit indicates the creator of the signature restoration data (i.e.,sanitizer 1) and the block number of the signature restoration data.

(Operation of Sanitizing Processing (2))

FIG. 53 is a view showing operation of the second and subsequent (i-th(i≧2)) sanitizing processing (2). The i-th sanitizing (changeprocessing) processing is as follows.

(S1) The document information management section 40A substitutes amessage to be undisclosed (changed) with a new message according to aninstruction of a sanitizer i. In FIG. 53, a message of block 4 ischanged from M4 to S4. S4 may be random information or information suchas XXXXXXXX that can be recognized as sanitized one at first sight. Inthe case of a change, S4 is set as information after change. It ispossible for the sanitizer i to apply a change once again to the partthat has been changed by the previous sanitizer (changer). A set of thedata after change is referred to as M(i).

(S2) The partial identification information generation section 51calculates the hush value (h(M4)) of the message block (M4) beforechange separately according to an instruction of the sanitizer. The hushvalue is called signature restoration data.

(S3) As is the case with the signature processing, the hush values arecalculated for respective blocks of M(i) to obtain hash value set H(i).

(S4) The digital signature creation section 80A uses the private key ofthe sanitizer i to create a digital signature for the hush value setH(i) according to an instruction of the sanitizer i. The signaturecreated is, for example, Sig_(i)=Sig(sk_(i),h(H(i))). This signifiesthat the hash value set is hushed once again, and the private key sk_(i)of the sanitizer i to append a signature to the resultant hush value setaccording to signature function Sig( ).

(S5) The document information management section 40A discloses themessage M(i) and signature Sig_(i) as well as the signatures Sig₀ andSig₁ to Sig_(i) of the signer and sanitizers 1 to i and signaturerestoration data ((3, h(M3), ID1), (5, h(M5), ID1), . . . (4, h(M4),IDi)) of the sanitizer 1 to i to a subsequent sanitizer (or verifier)according to an instruction of the sanitizer i.

(Operation of Signature Confirmation (Verification) Processing)

FIG. 54 is a view showing operation of the signature confirmation(verification) processing.

(S1) The partial identification information verification section 61restores the hash value set H(0) of the signer and the hash value setsH(1) to H(i) of the sanitizers 1 to i from the message M(i) andsignature restoration data according to an instruction of a verifier.

(S2) The partial identification information verification section 61 usesthe signature Sig₀ and hush value set H(0) of the signer to performsignature verification. After that, the partial identificationinformation verification section 61 uses the signatures Sig₁ to Sig_(i)and hash value sets H(1) to H(i) of the sanitizer 1 to i to performsignature verification.

(S3) When the above signature verification operations have beenperformed without problems, the signature confirmation of the messageM(i) ends.

The above processing certifies that a part having no signaturerestoration data is an original document that has been created andsigned by the singer, and that a part having signature restoration datais a part that has been sanitized or changed by the creator of thesignature restoration data.

In the first embodiment, while a differential information management isperformed with the latest partial identification information set as abase point, the same function as that of the underlying technique 2(SCCS type) can be realized. Further, a use of a feature capable ofcreating the latest partial identification information from the latestversion of the main body document eliminates the need to retain thepartial identification information serving as a base point.

According to the first embodiment, the basic function (assurance of thesecrecy of the nondisclosure portion and integrity of the disclosureportion) of the PIAT signature in the underlying technique 2 is keptretained. However, only the identification of the illegal sanitizing ismade disabled. This occurs because the differential informationmanagement of the first embodiment does not retain partialidentification information corresponding to the original (originaldocument). That is, in the case where the hash value hj corresponding toa partial document before sanitizing is falsified in sanitizinginformation (i, j, hj) (indicating that i-th partial document issanitized by j-th sanitizer and the hash value of a partial documentbefore sanitizing is hj), it is not possible to detect thisfalsification due to absence of the partial identification informationcorresponding to the original. Functions other than this point are thesame as those of the underlying technique 2.

The aforementioned operation will be described in line with the usagescene of the first phase in the underlying technique 1.

(Creation Time of New Document)

(A) Creation Time of New Agreement Document

The processing at the time of creation of a new agreement document isalmost the same as that described in the first phase shown in FIG. 6.Only a different point is that, in the registration/storage step(ST_R7), only an agreement document appended by a signature of “HanakoSuzuki” and a signature of “Hanako Suzuki” appended to partialidentification information are stored. In this case, the partialidentification information itself is not stored but discarded.

This is because that only with the agreement document, correspondingpartial identification information can be restored, and that only withthe signature of “Hanako Suzuki” appended to the partial identificationinformation corresponding the agreement document, the integrity of thepartial identification information restored from the agreement documentcan be assured.

(Correction Time)

(B) Correction Time of Agreement Document

A different point from the processing at correction time of an agreementdocument (FIG. 10) is that when “Hanako Suzuki” selects an agreementdocument to be changed, partial identification document corresponding tothe selected agreement document is restored in ST_U2. Subsequentprocessing is almost the same as that performed in the usage scene 1. Atthe storage time in the original document storage section (ST_U12), adifference between the restored partial identification information(first version) and generated partial identification information (secondversion) serving as a base point is taken, and the differenceinformation is stored as partial identification information difference(first version). Further, as is the case with processing at creationtime of a new agreement document, an agreement document (second version)appended by a signature of “Hanako Suzuki” and a signature of “HanakoSuzuki” appended to partial identification information (second version)are stored. Also in this case, the partial identification information(second version) itself is not stored but discarded (while the partialidentification information is not stored, it is necessary to create andstore information called “partial identification information difference”at creation time of the subsequent version).

(Verification Time)

(C) Verification Time of Integrity/Validity for Corrected AgreementDocument

The processing performed at verification time of the integrity/alidityfor a corrected agreement document is almost the same as that performedin the underlying technique 1. Only a different point is thatrestoration operation is newly added since partial identificationinformation is not stored. In ST_V6, a corrected agreement document(second version) is taken, and partial identification information(second version) is restored from the corrected agreement document(second version) by the partial identification information generationsection. Then, “partial identification information difference” (firstversion) is taken from the original document storage section, andpartial identification information (first version) is generated from therestored partial identification information (second version) and taken“partial identification information difference”.

As a result, all the information required for verification of theintegrity/validity made in the first phase: the corrected agreementdocument (original document) (second version) and its correspondingsignature of “Hanako Suzuki”; partial identification information (secondversion) and its corresponding signature of “Hanako Suzuki”; and partialidentification information (first version) and its correspondingsignature of “Hanako Suzuki” have been prepared. Subsequently, with thesame processing as that performed in the first phase, verification ofthe integrity/alidity for the corrected agreement document is completed.

In the second phase, by not storing the partial identificationinformation but instead storing “partial identification informationdifference” as described above and by restoring all partialidentification information from the “partial identification informationdifference” as needed, the same processing as that according to thebasic method can be employed.

(Sanitizing Time)

(B) Registration Data Correction Function (Used at the Time whenSanitizing is Partially Applied to an Agreement Document)

As is the case with the second phase of the underlying technique 1, itis only necessary for “Taro Sato” to perform (append a signature ofhimself the same processing as that described in “(B) Correction time ofagreement document” and the description thereof is omitted.

(Transmission Time)

(D) Registration Data Distribution (Transmission) Function (Used at theTransmission Time of an Agreement Document)

The processing to be performed here is almost the same as that accordingto the basic method except for the data to be transmitted. In theunderlying technique 1, an agreement document (third version) (agreementdocument sanitized by “Taro Sato”), partial identification information(first to third versions, or only second and third versions), partialcorrection information (third version), and policy information aretransmitted. On the other hand, in the first embodiment, an agreementdocument (third version) (agreement document sanitized by “Taro Sato”),partial identification information difference (first to third versions,or only second and third versions), partial correction information(third version), and policy information are transmitted. That is, thebasic method transmits the partial identification information itself;whereas the present method transmits the partial identificationinformation difference.

(Reception Time)

(E) Registration Data Distribution (Reception) Function (Used at theReception Time of an Agreement Document)

The processing to be performed here is entirely the same as thataccording to the basic method. The present method (C) is utilized as theverification process.

(Output Time of Third-Party Verification)

(F) Verification Data Acquisition Function (Used when an AgreementDocument is Exhibited as Evidence in a Court Case)

The processing to be performed here is entirely the same as thataccording to the basic method. As is the case with (D), the basic methodtransmits the partial identification information itself; whereas thepresent method transmits the partial identification informationdifference.

As described above, the underlying technique 1 manages all the partialidentification information (a) of an original document and all thepartial identification information (b) after correction, as shown inFIG. 55; whereas the first embodiment manages only the partialidentification information difference shown in (d) of FIG. 55. Theunderlying technique 2 uses a hierarchical structure of a document tostore differences ((c) of FIG. 55) between the partial identificationinformation (first version) ((a) of FIG. 55) and the second andsubsequent versions of the partial identification information. In thefirst embodiment, it is only necessary to store the differenceinformation, resulting in a significant reduction ofstorage/transmission data amount, as compared with the underlyingtechnique 2 (see FIG. 56). Even when compared with a case where theunderlying technique 2 functions most effectively, it is possible toreduce the storage/transmission data amount by the amount correspondingto that of the partial identification information (first edition) in thefirst embodiment.

Second Embodiment

As a method for further reducing the storage data in the firstembodiment, in the second embodiment, an embedding method of the changedifference information into a document will be described.

In the first embodiment, a verifier requires the same number of hushvalues as that of sanitized parts in addition to a document that hasbeen sanitized most recently. In this case, when the hash value of apartial document before sanitizing is used as data message M for use insanitizing the partial document, it is possible to eliminate the need toretain the hash value as sanitizing information.

The configuration of the second embodiment is the same as that used inthe first embodiment. However, there is a difference in operationbetween them as follows. The operation processing is performed in theprocessing section 41A shown in FIG. 50. The operation performed in thesecond embodiment will be described below.

(Operation of Signature Processing)

FIG. 57 is a view showing operation of the signature processing. Thecontent shown in FIG. 57 is entirely the same as that shown in FIG. 51.Accordingly, there is no difference in operation of signature processingbetween the first and second embodiments, and the description thereof isomitted.

(Operation of Sanitizing Processing (1))

FIG. 58 is a view showing operation of the first sanitizing processing(1) applied to an original document. A change in the first sanitizingprocessing is as follows.

(S1) The document information management section 40A uses, in place ofsanitizing information S, the hash value of partial identificationinformation before sanitizing calculated by the partial identificationinformation generation section 51 as signature restoration data to formthe document information and allows the partial identificationinformation generation section 51 to use it to generate the hush value.

In FIG. 58, H(M3) and h(M5) are used in place of S3 and S5.

(S2) Only the block number including a change and ID of the sanitizerthat has created the signature restoration data (in this case, (3, ID1),(5, ID1)) are disclosed in place of the signature restoration data.

Since the block number denotes a location where the signaturerestoration data has been embedded, it is not always necessary todisclose the block number. The ID may also be embedded in place of thesanitizing information S like the signature restoration data. Further,as shown in the part denoted by “e.g.” in FIG. 58, information may bestored as XML tag.

(Operation of Sanitizing Processing (2))

FIG. 59 is a view showing operation of the second and subsequent (i-th(i≧2)) sanitizing processing (2). The content shown in FIG. 59 isentirely the same as that shown in FIG. 58. Accordingly, there is nodifference in operation between the sanitizing processing (1) and (2).

(Operation of Signature Confirmation (Verification) Processing)

FIG. 60 is a view showing operation of the signature confirmation(verification) processing.

The signature confirmation processing according to the second embodimentis almost the same as that according to the first embodiment (FIG. 54)except that the hash value is restored not from the signatureconfirmation data but from the message of the changed block.

FIG. 61 is a conceptual view showing the operation of the secondembodiment. It can be seen from FIG. 61 that it is not at all necessaryto store the partial identification information as meta data. FIG. 62shows a result obtained by comparing the first and second embodimentswith the underlying technique 2. However, in the case where thesignature restoration data is embedded in the message, it is notpossible to deal with a change or deletion (in which block itself isdeleted). As a result, the information amount of the partialidentification information can be reduced several times to several tensof times from that in the underlying technique 1 and two to severaltimes from that in the underlying technique 2. Note that the informationamount of the partial identification information in the underlyingtechnique 2 can be reduced two to several times from that in theunderlying technique 1.

Third Embodiment

In the third embodiment, a case where an Aggregate signature scheme isapplied to the digital signature system will be described.

The Aggregate signature is a signature scheme capable of aggregating aplurality of signatures created by a plurality of signers andcollectively verifying the aggregated signature. At the time whenpartial identification information is generated in association withoccurrence of a correction and a signature is appended to the generatedpartial identification information as conventionally performed, theAggregate signature is performed to aggregate a new signature on thesignatures of previous versions. With this technique, it is possible toreduce the data amount of the digital signature which has been requiredby the number corresponding to that of versions to data amountcorresponding to that of one digital signature.

In the following description, (General/Sequential) Aggregate signature(KG/AS/AV) is used. KG is an algorithm for generating a key, AS is analgorithm for generating a signature, and AV is an algorithm forverifying a signature. A j-th signer receives documents M1, . . . , Mj−1and Aggregate signature σj−1 from a j−1th signer, uses the algorithm ASto generate a new Aggregate signature oj from a document Mj to which thej-th signer intends to append a signature and Aggregate signature σj−1,and outputs documents M1, . . . , Mj−1, Mj and Aggregate signature σj. Averifier of the Aggregate signature uses the algorithm AV to verify anAggregate signature σm for documents M1, . . . , Mm. When theverification results is valid, the integrity of all documents isassured.

The following documents are cited as reference sources.

[BGL+03] D. Boneh, C. Gentry, B. Lynn, and H. Shacham, “Aggregate andVeriflably Encrypted Signatures from Bilinear Maps.” Eurocrypt 2003,LNCS 2656, pp. 416-432. Springer-Verlag, 2003.

[LMR+04] A. Lysyanskaya, S. Micali, L. Reyzin, H. Schacham, “SequentialAggregate Signatures from Trapdoor Permutations” Eurocrypt 2004, LNCS3027, pp. 74-90 Springer-Verlag, 2004.

The Aggregate signature, which is a kind of a group signature scheme,can aggregate a plurality of signatures on one signature.

1) G₁, G₂, G_(T) constitute a cyclic group of order p

2) g₁ and g₂ are generation sources of G₁ and G₂

3) Ψ is a computable isomorphism mapping Ψ(g1)=g2 from G₁ to G₂

4) e( ) is a computable bilinear mapping G₁×G₂→G_(T)

When the above conditions 1) to 4) are satisfied, the following equationis satisfied.e(g ₁, σ)=e(g ₁,Π_(i) h _(i) ^(ski))=Πie(g ₁ ,h _(i))^(ski)=Π_(i) e(g ₁^(ski) ,h _(i))=Π_(i) e(pk _(i) ,h _(i))(where pk_(i)=g₁ ^(ski), σ₁=h_(i) ^(ski), σ=Π_(i)σ_(i))

Assuming that ski and pki are private key/public key and σ is Aggregatesignature, the superimposition of signatures can be realized.

Unlike with ordinary signature scheme, the output range of the hushfunction h is G₁. While the calculation of the Aggregate signature isperformed as described above, what is important in this example is asfollows.

What is important is, assuming that

signature of m1 in Aggregate signature function is set such thatσ1=SigA(sk1, m1) is satisfied,

signature of m2 in Aggregate signature function is set such that9∝2=SigA(sk2, m2) is satisfied, and

signature of m3 in Aggregate signature function is set such thatσ3=SigA(sk3, m3) is satisfied,

superimposition σ=σ1×σ2×σ3 of signature can be calculated, andverification can be performed using VerA(pk1, pk2,pk3,σa,m1,m2,m3) atsignature verification time.

It should be noted that, while

Ver(pk1,σ1,m1,m2,m3)

Ver(pk2,a2,ml,m2,m3)

Ver(pk3,σ3,m1,m2,m3) and

three signatures (σ1, σ2, σ3) are required in the ordinary signatureverification, only σ is required in the Aggregate signature, reducingthe data amount to one-third. σ1 to σ3 are called individual signatures,and aggregated signature σ is called Aggregate signature.

While the Aggregate signature using bilinear mapping is described in thepresent specification (General Aggregate Signature), there is availablea conventional Aggregate signature scheme based on RSA such as one thathas been proposed in the following papers.

[LMRS04] (Proposed Paper about Sequential Aggregate Signature)

A. Lysyanskaya, S. Micali, L. Reyzin, and H. Schacham, “SequentialAggregate Signatures from Trapdoor Permutations” Eurocrypt 2004, LNCS3027, pp. 74-90, 2004.

[TSNT05] (Modification of Sequential Aggregate Signature)

Isamu Teranishi, Kazue Sako, Jun Noda, Daigo Taguchi, “A New Lengthinvariant Sequential Aggregate Signature Scheme Based on RSA”Information Processing Society of Japan/Computer Security Group (CSEC)May, 2005.

Operation in association with the Aggregate signature will be describedbelow.

(Operation of Signature Processing)

FIG. 63 shows operation performed at signature time. A different pointis that an Aggregate signature function is used in place of a signaturefunction to calculate an individual signature σ0, and an Aggregatesignature σ(0) thus obtained is disclosed.

(Operation of Sanitizing Processing (1))

FIG. 64 is a view showing operation of the first sanitizing processing(1) applied to an original document.

A different point that, as in the case of the above signature processingoperation, an Aggregate signature function is used in place of asignature function to calculate an individual signature σ1, theAggregate signature σ(0) of the signer is multiplied by a sanitizer'sown individual signature σ1, and only thus obtained Aggregate signatureσ(1) is disclosed.

(Operation of Sanitizing Processing (2))

FIG. 65 is a view showing operation of the second and subsequent (i-th(i≧2)) sanitizing processing (2). The content shown in FIG. 65 isentirely the same as that shown in FIG. 64. Accordingly, there is nodifference in operation between the sanitizing processing (1) and (2).

(Operation of Signature Confirmation (Verification) Processing)

FIG. 66 is a view showing operation of the signature confirmation(verification) processing.

Only a different point from the signature verification shown in FIG. 54is that verification is made for the Aggregate signature.

In the PIAT signature described in the abovementioned underlyingtechniques 1 and 2, and first and second embodiments, the verifierrequires m+1 signatures created by a signer and m sanitizers. By usingthe Aggregate signature in place of these signatures, it is possible toreduce the requisite number of signatures to one (FIG. 67). However, therequisite number of partial identification information is not changed.By applying the Aggregate signature scheme to the abovementionedunderlying techniques 1 and 2, and first and second embodiments, it isalso possible to reduce the number of signatures to be managed in theabove document management techniques to one (FIG. 68). In this case,however, identification of an illegal sanitizer is made disabled. Thisis because that when the verification for the Aggregation signaturefails, it is impossible to identify for which singer/sanitizer'ssignature the verification has failed. Other functions of the Aggregatesignature at the signature verification time are the same as those inthe PIAT signature.

By combining the configuration of the second embodiment and Aggregatesignature scheme of the third embodiment, a significant storage datareduction can be realized. Further, this combined configuration requiresonly one signature and no hash value, realizing an optimal configurationfrom the viewpoint of the data amount that the verifier requires. Evenin this case, the required minimum function as a sanitizable signaturescheme can be realized.

In the following, a case will be described where the Aggregate signatureis performed by taking a concrete example constituted by “Hanako Suzuki”and other two persons (Taro Sato and Minoru Yamada) who have appeared inthe underlying technique 2.

(Preparation)

In the case where the Aggregate signature scheme is applied, “HankoSuzuki”, “Taro Sato”, and “Minoru Yamada” have a key for signaturecorresponding to an Aggregate signature respectively. Further, commonparameters for signature are shared between them. Since the data amountof the signature to be appended to an agreement document main body isnot reduced even with application of the Aggregate signature in the caseof the example of the scene 1, the Aggregate signature is applied to thesignature to be appended to the partial identification information. Thesignature to be appended to individual documents (partial identificationinformation) is called individual signature, and the signature obtainedby aggregating the individual signatures using shared information iscalled aggregated signature. In the verification using the Aggregatesignature scheme, it is only necessary to perform verification for theaggregated signature and respective documents (partial identificationinformation). In this case, verification for the individual signaturesis not necessary.

The Aggregate signature scheme can be described as follows:

Creation of individual signatures for documents Mi=creation of anaggregated signature from (σi=Sign(Mi)n) individual signaturesσ=σ0×σ1×σ2× . . . σn

For example, in the case of the Aggregate signature scheme usingbilinear mapping, Sign(Mi) is realized by a signature scheme based on anelliptic curve cryptosystem, and the aggregated signature creation canbe realized by multiplication residue arithmetic on the method P(parameters of Aggregate signature) of the individual signatures.

(New Document Creation Time)

(A) Creation Time of New Agreement Document

Partial identification information corresponding to a new agreementdocument is generated at the time when the agreement document iscreated, and a signature of “Hanako Suzuki” is appended thereto. Thesignature created at this time is regarded as an individual signature of“Hanako Suzuki” in the Aggregate signature scheme. The individualsignature of “Hanako Suzuki” is used as the first aggregated signature,and the individual signature itself is discarded. Assuming that theaggregated signature is σ and individual signature of “Hanako Suzuki”for the partial identification information is σ1, an expression σ←σ1 canbe obtained (“←” represents substitution).

(Correction Time)

(B) Registration Data Correction Function (Used at the Time whenSanitizing is Partially Applied to an Agreement Document)

At the data correction time, an individual signature of “Hanako Suzuki”is appended to partial identification information corresponding to acorrected agreement document. Subsequently, as an aggregated signature,the individual signature of “Hanako Suzuki” appended to the partialidentification information (second version) is aggregated on theaggregated signature appended to the first version. After that, theindividual signature of “Hanako Suzuki” is discarded. Assuming that theaggregated signature is σ and individual signature of “Hanako Suzuki”for the partial identification information (second version) is σ2, anexpression σ←σ×σ2 can be obtained.

(Verification Time)

(C) Integrity/Validity Verification Time of Corrected Agreement Document

Signature verification is performed using the restored partialidentification information (first and second versions) and aggregatedsignature according to the verification processing of the Aggregatesignature scheme.

(Sanitizing Time)

(B) Registration Data Correction Function (this Function is Used whenSanitizing is Applied to the Agreement Document)

The Aggregate signature processing entirely the same as that performedat the correction time is performed.

(Transmission Time)

(D) Registration Data Distribution (Transmission) Function (Used at theTransmission Time of an Agreement Document)

At the data transmission time, signature/signature verificationprocessing is not performed. The data to be transmitted is almost thesame as those described above. Only a different point is that not thesignatures corresponding to respective versions of partialidentification information, but one aggregated signature is transmitted.

(Reception Time)

(E) Registration Data Distribution (Reception) Function (Used at theReception Time of an Agreement Document)

At the data reception time, the same processing as that performed at the(B) verification time is performed.

(Output Time of Third-Party Verification)

(F) Verification Data Acquisition Function (Used when an AgreementDocument is Exhibited as Evidence in a Court Case)

At the data transmission time, signature/signature verificationprocessing is not performed. The data for verification is almost thesame as those described above. Only a different point is that not thesignatures corresponding to respective versions of partialidentification information, but one aggregated signature is output.

As described above, two signatures of “Hanako Suzuki” and one signatureof “Taro Sato” needs to be stored/transmitted when ordinary signatureprocessing is applied to the data corresponding to partialidentification information; whereas, when the Aggregate signature schemeis applied, the above three signatures are aggregated on one aggregatedsignature and therefore it is only necessary to store/transmit oneaggregated signature, significantly reducing storage/transmission dataamount.

Further, it is possible to provide a digital document management programaccording to the present invention by preparing a program that allows acomputer to execute the above operation shown in the flowcharts orsteps. By storing the above program in a computer-readable storagemedium, it is possible to allow the computer to execute the program. Thecomputer-readable medium mentioned here includes: a portable storagemedium such as a CD-ROM, a flexible disk, a DVD disk, a magneto-opticaldisk, or an IC card; a database that holds computer program; anothercomputer and database thereof; and a transmission medium on a networkline.

1. A digital document management program that allows a computer tomanage document information created and registered in a digital form,the program allowing the computer to execute: a partial identificationinformation generation step that divides the document information into aplurality of parts and generates partial identification information thatrepresents, in an identifiable manner, the respective parts of thedocument information based on information included in the respectiveparts; a digital signature creation step that creates a digitalsignature to be appended to the document information using the partialidentification information; a management step that manages the documentinformation; and a verification step that verifies the validity of themanaged document information, wherein at the registration time of newdocument information, the management step manages a digital signaturecreated by the digital signature creation step in association with thedocument information and, at the correction time of the documentinformation, it acquires partial identification information related to acorrected part of the document information before correction, allows thedigital signature creation step to create a digital signature to beappended to the corrected document information, and manages the digitalsignature and partial identification information related to thecorrected part of the document information before correction inassociation with the corrected document information, and theverification step uses the partial identification information anddigital signature managed in association with the corrected documentinformation by the management step and partial identificationinformation newly created from the corrected document information by thepartial identification information generation step to perform theverification.
 2. The digital document management program according toclaim 1, wherein the digital signature creation step uses a set ofpartial identification information created by the partial identificationinformation generation step and a private key as parameters to create adigital signature according to a signature function.
 3. The digitaldocument management program according to claim 1, wherein the digitalsignature creation step uses an Aggregate signature function which is akind of a group signature scheme and which is capable of aggregating aplurality of signatures on one signature.
 4. The digital documentmanagement program according to claim 1, wherein the partialidentification information managed in association with the correcteddocument information is managed separately from the corrected documentinformation data.
 5. The digital document management program accordingto claim 1, wherein the partial identification information is managed bybeing embedded in the corrected document information.
 6. The digitaldocument management program according to claim 1, further comprising: apolicy information storage step that stores previously defined policyinformation; and a partial correction information generation step thatgenerates partial correction information which is information related toa correction history of a corrected part in the case where anycorrection has been made for the document information, wherein in thecase where any correction has been made for a part of the documentinformation, the management step allows the partial correctioninformation generation step to generate partial correction informationand manages the generated partial correction information and policyinformation stored by the policy information storage step in associationwith the corrected document information, and the verification step usesthe partial correction information and policy information in addition tothe partial identification information and signature information managedin association with the corrected document information by the managementstep to verify the validity of the document information.
 7. The digitaldocument management program according to claim 1, the partialidentification information generation step divides document informationinto a plurality of parts and uses a hash function to generate partialidentification information for respective parts of the documentinformation.
 8. The digital document management program according toclaim 1, wherein the information managed by the management step isconstituted by XML data having a hierarchical document structure.
 9. Thedigital document management program according to claim 1, wherein themanagement step handles all digital information as original documentinformation corresponding to version numbers, and an access to thecontent of the original document information managed based on itsversion numbers can be controlled depending on the content thereof inthe respective versions in an identifiable manner.
 10. A digitaldocument management system that manages document information created andregistered in a digital form, comprising: a partial identificationinformation generation section that divides the document informationinto a plurality of parts and generates partial identificationinformation that represents, in an identifiable manner, the respectiveparts of the document information based on information included in therespective parts; a digital signature creation section that creates adigital signature to be appended to the document information using thepartial identification information; a management section that managesthe document information; and a verification section that verifies thevalidity of the managed document information, wherein at theregistration time of new document information, the management sectionmanages a digital signature created by the digital signature creationsection in association with the document information and, at thecorrection time of the document information, it acquires partialidentification information related to a corrected part of the documentinformation before correction, allows the digital signature creationsection to create a digital signature to be appended to the correcteddocument information, and manages the digital signature and partialidentification information related to the corrected part of the documentinformation before correction in association with the corrected documentinformation, and the verification section uses the partialidentification information and digital signature managed in associationwith the corrected document information by the management section andpartial identification information newly created from the correcteddocument information by the partial identification informationgeneration section to perform the verification.
 11. The digital documentmanagement system according to claim 10, wherein the digital signaturecreation section uses a set of partial identification informationcreated by the partial identification information generation section anda private key as parameters to create a digital signature according to asignature function.
 12. The digital document management system accordingto claim 10, wherein the digital signature creation section uses anAggregate signature function which is a kind of a group signature schemeand which is capable of aggregating a plurality of signatures on onesignature.
 13. The digital document management system according to claim10, wherein the partial identification information managed inassociation with the corrected document information is managedseparately from the corrected document information data.
 14. The digitaldocument management system according to claim 10, wherein the partialidentification information is managed by being embedded in the correcteddocument information.
 15. The digital document management systemaccording to claim 10, further comprising: a policy information storagesection that stores previously defined policy information; and a partialcorrection information generation section that generates partialcorrection information which is information related to a correctionhistory of a corrected part in the case where any correction has beenmade for the document information, wherein in the case where anycorrection has been made for a part of the document information, themanagement section allows the partial correction information generationsection to generate partial correction information and manages thegenerated partial correction information and policy information storedby the policy information storage section in association with thecorrected document information, and the verification section uses thepartial correction information and policy information in addition to thepartial identification information and signature information managed inassociation with the corrected document information by the managementsection to verify the validity of the document information.
 16. Thedigital document management system according to claim 10, the partialidentification information generation section divides documentinformation into a plurality of parts and uses a hash function togenerate partial identification information for respective parts of thedocument information.
 17. The digital document management systemaccording to claim 10, wherein the information managed by the managementsection is constituted by XML data having a hierarchical documentstructure.
 18. The digital document management system according to claim10, wherein the management section handles all digital information asoriginal document information corresponding to version numbers, and anaccess to the content of the original document information managed basedon its version numbers can be controlled depending on the contentthereof in the respective versions in an identifiable manner.
 19. Adigital document management method that manages document informationcreated and registered in a digital form by a computer, comprising: apartial identification information generation step that divides thedocument information into a plurality of parts and generates partialidentification information that represents, in an identifiable manner,the respective parts of the document information based on informationincluded in the respective parts; a digital signature creation step thatcreates a digital signature to be appended to the document informationusing the partial identification information; a management step thatmanages the document information; and a verification step that verifiesthe validity of the managed document information, wherein at theregistration time of new document information, the management stepmanages a digital signature created by the digital signature creationstep in association with the document information and, at the correctiontime of the document information, it acquires partial identificationinformation related to a corrected part of the document informationbefore correction, allows the digital signature creation section tocreate a digital signature to be appended to the corrected documentinformation, and manages the digital signature and partialidentification information related to the corrected part of the documentinformation before correction in association with the corrected documentinformation, and the verification step uses the partial identificationinformation and digital signature managed in association with thecorrected document information by the management step and partialidentification information newly created from the corrected documentinformation by the partial identification information generation step toperform the verification.
 20. The digital document management methodaccording to claim 19, wherein the digital signature creation step usesa set of partial identification information created by the partialidentification information generation step and a private key to create adigital signature according to an Aggregate signature function which isa kind of a group signature scheme and which is capable of aggregating aplurality of signatures on one signature.